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1.  INTRODUCTION 

The  Navy  Fleet  Material  Support  Office  (FMSO)  is  currently 
evolving  an  integrated,  real-time  data  communications  network 
to  provide  a  large  number  of  dispersed  Navy  sites  with  logistics 
information  necessary  for  effective  and  efficient  logistics 
support.  The  Logistics  Data  Communications  Network  (LDCN)  will 
enable  remote  sites  to  directly  access  major  logistic  data 
bases  at  two  Inventory  Control  Points  (ICP's)  located  at  the 
Ship  Parts  Control  Center  (SPCC)  ,  Harrisburg,  Pennsylvania,  and 
the  Aviation  Supply  Office  (ASO) ,  Philadelphia,  Pennsylvania. 
Programmable  communications  concentrators  at  selected  remote  sites 
will  be  used  for  cost-effective  interfacing  of  low  speed  term¬ 
inals  with  the  computer  complexes  managing  the  data  bases. 

These  complexes  each  have  two  U494  computers;  SPCC  also  has  an 
IBM  360/65,  while  ASO  has  a  Burroughs  3500.  Interdata  7/32 
minicomputers  will  act  as  Front  End  Processors  (FEP's)  at  each 
of  these  complexes  to  serve  the  communication  functions  for  the 
main  computers.  In  addition,  FMSO  has  designated  the  FEP's  to 
be  the  collectors  and  recorders  of  statistical  data  for  the  LDCN. 

Many  times  in  the  past,  the  statistics  collected  and  reported 
by  a  network  were  afterthoughts  of  the  design  process.  In  these 
networks,  certain  key  statistics  were  either  not  collected  or 
required  a  high  processing  overhead  to  collect,  while  reports 
were  generally  unreadable  with  important  information  buried  among 
reams  of  statistics  of  questionable  merit.  In  these  systems, 
statistics  quickly  fell  into  disuse,  causing  network  management 
to  be  driven  primarily  by  network  events  such  as  failures, 
rather  than  network  management  being  the  primary  driver  of 
events  for  network  efficiency.  Recognizing  the  pitfall  of 
this  approach,  FMSO  has  identified  the  need  to  formulate  a 
comprehensive  statistics  package  in  the  early  design  stages  of 
the  FEP .  As  input  to  this  formulation,  FMSO  requested  Network 
Analysis  Corporation  (NAC)  to  study  statistics  for  the  LDCN  and 
generate  concepts  for  the  implementation  of  such  a  package. 

This  report  is  a  summary  of  those  concepts. 
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1.1  Goals  and  Constraints 

The  purpose  of  NAC's  statistical  study  is  to  describe 
functionally  a  statistical  package  for  the  LDCN,  including: 

•  Identification  and  functional  description  of  the 
statistics  appropriate  in  reports  for  operational 
management,  network  operators,  and  network  engineers. 

•  Identification  of  the  data  to  be  obtained  from  the 
LDCN  to  enable  the  statistics  processing. 

•  Identification  of  the  mechanisms  and  their  place¬ 
ment  for  obtaining  the  necessary  data. 

•  Description  of  the  processing  mechanisms  to  trans¬ 
form  the  data  into  desired  reports. 

This  report  is  the  result  of  that  study,  and  serves  as 
an  input  to  the  FMSO  statistical  design  team.  Both  FMSO  and  NAC 
recognize  that  only  FMSO  has  all  the  facts  on  its  needs  and 
the  resources  available  to  implement  a  statistical  package.  As 
such,  only  a  fraction  of  the  concepts  described  here  might  be 
implemented  in  the  LDCN.  Thus,  this  report  is  not  a  description 
of  what  the  LDCN  statistical  package  might  be,  but  rather  a 
comprehensive  input  to  facilitate  determination  and  implemen¬ 
tation  of  an  appropriate  package  by  FMSO. 

At  the  start  of  this  study,  FMSO  suggested  NAC  consider 
three  constraints  to  the  problem.  Upon  evaluation  by  NAC, 
these  constraints  were  deemed  reasonable  and  followed.  The 
three  constraints  were: 

•  Statistics  should  be  designed  for  the  LDCN.  NAC  could 
use  its  knowledge  of  the  statistics  collected  on  other 
networks,  but  the  concepts  generated  by  NAC  for  FMSO 
consideration  had  to  relate  to  the  LDCN. 
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•  The  majority  of  the  statistical  data  should  be 
collected  by  the  front  ends,  not  the  concentrators  or 
host  computers.  The  concentrators  could  do  some 
statistical  collection,  but  would  be  limited  since 
all  statistical  data  would  be  kept  in  primary  storage. 
The  front  ends  were  to  eliminate  processing  overhead 
in  the  hosts;  thus  it  does  not  make  sense  to  place 
statistics  in  the  hosts  when  the  front  ends  should 
have  sufficient  host  statistical  data  available  from 
their  normal  communications  with  the  hosts. 

•  Only  essential  statistics  should  be  processed  on-line. 

By  essential  statistics  we  mean  the  network  status 
information  needed  by  operational  personnel  to  respond 
to  immediate  network  problems. 

Once  again,  it  should  be  noted  that  this  report  describes 
a  way  statistics  could  be  collected  in  the  LDCN ,  not  the  way 
statistics  will  be  collected  in  the  LDCN. 

1 . 2  Organization 

This  report  on  statistics  is  divided  into  six  sections 
and  one  appendix.  Section  2  gives  an  overview  of  the  LDCN, 
statistics,  and  network  management.  Section  3  deals  with  the 
design  of  statistical  reports  for  managers,  operators,  and 
engineers.  The  measurement  mechanisms  needed  to  obtain 
statistical  data  is  presented  in  Section  4,  while  the  algorithms 
to  convert  the  raw  data  into  meaningful  statistics  is  given 
in  Section  5.  Section  6  summarizes  the  findings  of  the  pre¬ 
vious  sections.  Finally,  Appendix  A  describes  some  of  the 
statistics  collected  by  current  systems.  This  appendix  is 
for  background  information  only;  it  does  not  provide  every 
detail  of  the  statistics  collected  on  current  networks,  for 
that  is  beyond  the  scope  of  this  study. 
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2.  SYSTEM  MANAGEMENT 

In  order  to  develop  a  statistical  package  for  the  LDCN, 
one  must  first  have  an  overview  of  the  network.  To  this  end, 
Section  2.1  presents  an  overview  of  the  LDCN.  The  information 
in  this  section  is  a  summary  of  discussions  with  FMSO  personnel 
and  the  documentation  of  network  concepts  found  in  the  references 
of  Table  2.1.  For  further  information  on  the  LDCN,  one  is 
referred  to  these  documents. 

Besides  having  an  overview  of  the  LDCN,  a  designer  needs 
an  overview  of  the  role  statistics  play  in  network  control 
and  management  functions  in  order  to  design  an  effective 
statistical  package.  Section  2.2  deals  with  this  topic. 

Finally,  Section  2.3  discusses  the  need  for  a  manual  measure¬ 
ment  subsystem  in  a  network  statistical  package.  This  sub¬ 
system  creates  a  central  file  of  descriptive  information  on 
the  network.  Because  of  the  marw  al  nature  of  this  subsystem, 
it  is  often  overlooked  by  designers  of  statistical  packages. 


LDCN  Configuration 


FMSO  manages  major  logistics  data  bases  at  two  ICP's; 
one  at  the  Ship  Parts  Control  Center  (SPCC)  at  Mechanicsburg, 
Pennsylvania,  and  the  other  at  the  Aviation  Supply  Office  (ASO) 
at  Philadelphia,  Pennsylvania.  The  SPCC  computer  complex  con¬ 
tains  two  U494  computers  and  an  IBM  360/65.  The  ASO  computer 
complex  contains  two  U494  computers  and  a  Burroughs  3500. 

At  each  ICP ,  one  U494  supports  real-time  processing  activity 
for  an  Inventory  Control  (IC)  data  base,  and  the  other  U494 
supports  real-time  processing  for  a  Weapons  System  (WS)  data 
base.  At  both  locations,  each  U494  can  access  the  other's 
data  base  in  a  read-only  mode.  The  IBM  360/65  maintains  a 
Material  Maintenance  Management  (3M)  data  base,  and  the  B3500 
is  used  to  track  progress  of  high  priority  stock  transactions 
for  air  logistics  support. 
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Approximately  775  terminals  will  access  the  data  bases 
through  nine  programmable  communications  piocessors  used  as 
concentrators.  Two  of  the  nine  concent iitors  will  be  located 
at  SPCC  for  local  terminal  access,  and,  similarly,  two  will 
be  located  at  ASO.  The  remaining  five  concentrators  will  be 
located  in  Washington,  DC,  San  Diego,  California,  Oakland, 
California,  Jacksonville,  Florida,  and  Norfolk,  Virginia. 

The  tentative  network  architecture  calls  for  each  of  the 
concentrators  to  be  dual-homed  to  the  two  ICP's.  An  estimate 
of  the  terminal  distribution  by  location  and  category  is 
shown  in  Figure  2.1. 

The  FEP's  will  serve  to  interface  the  main  computers  at 
each  ICP  with  the  remote  concentrators .  The  concentrator- 
FEP  connections  are  tentatively  planned  to  be  through  dedicated 
9600  bps  circuits.  The  FEP-main  computer  connections  are 
tentatively  planned  to  be  through  direct  channel  interfaces. 

The  FEP's  will  also  be  used  to  interface  with  the  AUTODIN 
C DC-1700  interface  terminals,  one  interface  at  each  ICP. 

The  interface  will  be  through  dedicated  1200  bps  or  2400  bps 
circuits . 

The  overall  network  configuration  is  shown  in  Figure  2.1. 
2.1.1  System  Operation 

The  system  operation  is  transaction  oriented,  with  two 
basic  types  of  transactions:  upquiries  to  update  the  data 
base,  and  inquiries  to  extract  information  from  the  data 
base.  The  transactions  may  also  be  divided  into  those  requiring 
real-time  processing  and  those  which  may  be  grouped  for 
batch  processing.  For  convenience,  we  will  identify  those 
requiring  real-time  processing  as  RTT's  (Real-Time  Trans¬ 
actions)  and  those  which  may  be  grouped  for  batch  processing 
as  PBT’s  (Possible-Batched  Transactions).  PBT’s  are  batched 
according  to  application  programs,  with  a  processing  schedule 
based  on  batch  size,  waiting  time,  and  absolute  time. 
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Both  RTT's  and  PBT's  may  enter  the  system  through  inter¬ 
active  terminals.  Remote  Job  Entry  (RJE)  terminals  and  the 
AUTODIN  interface  are  assumed  to  enter  PBT's  99%  of  the  time. 
The  system  operation  is  described  below  in  terms  of  these 
three  methods  of  transaction  entry  and  the  handling  of  batched 
transactions . 

2.1.2  Interactive  Terminals 


The  system  operation  is  best  described  in  terms  of  the 
user  activities  at  the  terminal.  The  initiation  of  an  up- 
quiry  or  inquiry  first  requires  establishment  of  communications 
with  the  system.  The  terminal  operator  does  this  by  initi¬ 
ating  a  request  for  service  by  typing  the  HERE-IS  character. 
This  signals  the  concentrator  that  a  new  activity  is  to  be 
commenced,  and  the  concentrator  signifies  its  ready  status 
by  return  of  the  characters  "USER-ID:".  The  operator  then 
enters  his  USER-ID  and  depresses  the  END-OF-TEXT  key.  The 
concentrator  responds  with  the  characters  "PASSWORD:"  followed 
by  three  eight-character  random  series  overprinted  one  on  the 
other.  The  user  keys  in  his  password  in  the  overprinted  area 
and  depresses  the  END-OF-TEXT  key.  The  concentrator  then 
verifies  the  password;  if  not  correct,  the  concentrator  will 
request  the  password  two  more  times  before  disconnecting  the 
terminal.  If  the  password  is  correct,  the  concentrator 
responds  with  the  prompt  "SYSTEM:".  The  user  then  keys  in 
the  system  code  for  the  system  he  wishes  to  access.  The 
system  codes  are: 

AICS  =  ASO  -  Inventory  Control  System 
AWPS  =  ASO  -  Weapons  System 
ASCC  =  ASO  -  Air  Station  Control  Center 
AANY  =  ASO  -  either  U494  (ICS  or  WPS) 


NETWORK  ANALYSIS  CORPORATION 


ATST  =  ASO  -  test  system 

SICS  =  SPCC  -  Inventory  Control  System 

SWPS  =  SPCC  -  Weapons  System 

SMMM  =  SPCC  -  3M  System 

SANY  =  SPCC  -  either  U494  (ICS  or  WPS) 

STST  =  SPCC  -  test  system 

Upon  a  successful  sign-on  the  concentrator  responds  with  the 
prompt  and  forwards  the  sign-on  information  to  the  FEP. 

This  affirmative  response  then  allows  the  terminal  operator 
to  enter  the  appropriate  data.  When  this  activity  is  complete, 
the  concentrator  has  within  it  the  transaction  (upquiry  or 
inquiry)  for  transfer  to  the  appropriate  FEP.  The  concentrator 
then  adds  an  appropriate  routing  header  to  the  transaction, 
and  queues  the  transaction  with  transactions  from  other  terminals 
for  transfer  to  the  appropriate  FEP. 

After  transfer  of  the  transaction  to  the  FEP  is  complete, 
the  FEP  examines  the  transaction,  and  if  the  transaction  is 
identified  as  an  RTT,  it  is  immediately  placed  on  queue  for 
transfer  to  the  appropriate  main  computer.  If  the  trans¬ 
action  is  identified  as  a  PBT ,  it  is  placed  on  the  appropriate 
application  queue,  and  will  remain  there  until  the  applica¬ 
tion  batch  is  to  be  processed. 

Processing  of  transactions  by  the  main  computer  results 
in  outputs  to  be  returned  to  the  user.  These  outputs  are 
immediately  transferred  from  the  main  computers  to  the  FEP 
where  they  are  then  processed  to  determine  appropriate 
routing,  and  queued  for  transfer  to  the  appropriate  concen¬ 
trator. 
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The  current  design  of  the  concentrator  does  not  use 
auxiliary  storage  for  buffering.  Consequently,  the  FEP  must 
queue  the  output  until  the  concentrator  has  sufficient 
buffering  available  for  the  first  part  of  the  output  to  be 
delivered  to  the  terminal.  Once  transfer  of  the  output 
from  the  FEP  is  initiated,  the  concentrator  continuously 
delivers  the  output  to  the  terminal,  using  double  buffering 
to  enable  the  request  of  each  new  part  of  output  from  the  FEP 
without  an  interruption  in  transmission  to  the  terminal. 

The  life  cycle  of  the  transaction  is  complete  when  the  last 
character  of  the  output  is  delivered  to  the  terminal. 

There  may  be  considerable  time  between  the  completion 
of  the  transaction  input  and  return  of  the  output.  During 
this  time,  the  operator  may  initiate  input  of  another  trans¬ 
action.  If  this  is  done,  transmission  of  an  output  to  the 
terminal  must  wait  for  completion  of  the  input  process.  In 
addition,  at  any  time  after  signing-on  a  user  can  change 
systems  at  the  complex  to  which  he  has  access  by  keying  in 
the  characters  "SYSTEM:  XXXX"  where  XXXX  is  the  new  system 
code . 

A  user  completes  a  session  on  a  terminal  by  using  the 
"OFF"  command  or  depressing  the  HERE-IS  key  to  initiate  a 
new  sign-on.  When  this  information  is  forwarded  to  the 
FEP,  the  FEP  must  hold  all  outputs  received  for  that 
terminal  and  USER-ID  until  its  next  sign-on. 

2.1.3  Remote  Job  Entry 

Several  RJE  terminals  (card  readers  plus  line  printers) 
will  be  connected  to  the  concentrators  to  facilitate  entry  of 
batched  transactions.  In  this  mode  of  operation,  each  trans¬ 
action  will  be  on  one  card.  The  concentrator  will  simply 
receive  the  transactions,  determine  the  FEP  to  which  they  are 
to  be  forwarded,  and  place  them  on  the  appropriate  queue  with 
the  appropriate  header  for  transmission  to  the  FEP.  Because 
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the  concentrator  does  not  have  auxiliary  storage  buffering, 
provision  must  be  made  for  the  concentrator  to  control  the 
RJE  input  on  the  basis  of  buffer  availability,  or  for  the 
RJE  transactions  to  have  sufficient  priority  to  ensure  that 
their  transmission  to  the  FEP  is  consistently  faster  than 
their  input  to  the  concentrator. 

Once  the  RJE  transactions  reach  the  FEP,  they  are  pro¬ 
cessed  as  ordinary  PBT's.  This  processing  is  described 
in  Section  2.1.5.  It  is  assumed  that  transactions  entered 
by  RJE  will  be  primarily  PBT's,  but  with  an  occasional 
RTT  (1%)  . 

2.1.4  AUTODIN  Entry 


The  FEP  will  receive  transactions  through  the  AUTODIN 
interface.  These  transactions  will  basically  be  handled  by 
the  FEP  in  the  same  manner  as  transactions  received  from  RJE 
terminals  through  the  concentrator.  However,  some  additional 
processing  for  editing  will  be  necessary. 

2.1.5  FEP  Operation 

The  FEP  will  receive  transactions  from  the  AUTODIN  inter¬ 
face  and  from  the  concentrators.  As  the  transactions  are 
received,  they  are  identified  as  RTT's  or  PBT's.  RTT 1 s  are 
immediately  placed  on  queue  for  transfer  to  the  appropriate 
main  computer.  PBT's  are  placed  on  the  appropriate  appli¬ 
cation  queue . 

Each  application  queue  will  be  a  batch  for  processing 
by  the  appropriate  main  computer.  Each  batch  will  have  a 
processing  schedule  that  may  be  based  on  batch  size,  waiting 
time,  or  periodic  processing.  Examples  of  such  rules  are: 
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a.  Process  every  three  hours  or  whenever  the  batch 
reaches  50  transactions. 

b.  Process  whenever  the  batch  reaches  20  transactions 
or  whenever  the  longest  waiting  transaction  has 
waited  six  hours. 

c.  Process  at  8:00  p.m. 

When  a  transaction  entered  through  a  concentrator  is 
processed  by  a  main  computer,  an  output  is  generated  for 
return  to  the  user.  This  output  is  immediately  transferred 
to  the  FEP.  If  the  transaction  was  an  RTT,  the  output  is 
immediately  queued  for  transfer  to  the  appropriate  concen¬ 
trator.  The  transfer  will  be  effected  as  described  earlier. 

If  the  transaction  is  a  PBT ,  the  output  will  be  destined 
for  a  line  printer.  The  outputs  are  queued  on  the  basis  of 
destination  until  the  batch  processing  is  complete.  The  out¬ 
puts  destined  for  line  printers  will  then  be  transferred  to 
the  appropriate  concentrators  with  the  same  double  buffering 
technique  described  earlier  for  RTT's. 

Not  all  transactions  arriving  over  the  AUTODIN  inter¬ 
face  will  generate  outputs.  The  outputs  that  are  generated 
will  be  immediately  transferred  to  the  FEP  where  they  will 
be  queued  until  a  full  AUTODIN  message  is  formed  or  until 
the  batch  processing  is  complete.  The  FEP  processes  the 
outputs  to  place  them  in  proper  AUTODIN  message  format, 
and  then  transfers  the  message  to  the  AUTODIN  host  processor. 
This  process  will  continue  until  all  outputs  have  been 
transferred. 
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2 . 2  Network  Control  and  Management  Functions 

One  of  the  major  aspects  in  the  design  of  a  communications 
network  is  the  network  control  and  management  functions.  The 
LDCN  is  no  exception;  many  such  functions  can  be  identified 
for  the  LDCN,  including: 

•  System  Monitoring  and  Notification:  The  LDCN  should 
be  able  to  identify  inoperable  system  elements  and 
notify  appropriate  parties. 

•  Facility  Monitoring  and  Correction:  Circuit  error 
rates  and  operating  conditions  should  be  monitored, 
and  when  unacceptable,  corrective  action  such  as 
dial-backup  should  be  executed. 

•  Diagnostic  Assistance:  When  facilities  fail,  the 
LDCN  should  be  able  to  provide  assistance  to  an 
operator  or  other  remote  intelligence  to  isolate 
the  cause  of  failure. 

•  Flow  C  >r*trol:  The  LDCN  should  provide  a  mechanism 
for  graceful  degradation  of  performance  during 
overload  conditions. 

•  Operational  Statistics :  The  LDCN  should  gather 
operational  statistics,  such  as  circuit  error  rates 
and  failure  frequency,  to  enable  system  reconfig¬ 
uration  as  required. 

•  Traffic  Statistics:  Statistics  on  message  lengths, 
message  types,  etc.,  should  be  obtained  to  permit 
system  design  changes  as  required  and  for  future 
design  efforts. 
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•  Performance  Statistics :  Throughput  and  delays  should 
be  measured  to  enable  calibration  of  system  per¬ 
formance  . 

•  Utilization  Statistics:  Processor  utilization, 
buffer  utilization,  etc.,  should  be  measured  to 
enable  identification  and  correction  of  marginal 
situations  before  bottlenecks  develop. 

•  System  Component  Statistics:  A  list  of  components 
(terminals,  lines,  modems,  processors)  with  cost  and 
functional  specifications  should  be  kept  for  network 
design  purposes. 

•  System  Location  Statistics:  Each  location  containing 
LDCN  components  should  have  a  record  containing  site 
name,  address,  phone  number,  and  V&H  coordinates  (or 
latitude  and  longitude) .  These  records  would  be 
used  in  network  design  and  maintenance  functions. 

•  Monthly  Cost  Statistics:  Every  month  a  breakdown 
of  system  costs  -  line  charges,  drop  charges, 

Telpak  charges,  processor  charges,  maintenance 
charges,  and  possibly  personnel  charges  -  should  be 
produced.  These  statistics  would  keep  management 
informed  of  the  cost  of  providing  network  services 
to  its  customers. 

•  Operating  System  Characteristics:  Documents  describing 
the  line  disciplines,  polling  sequences,  addressing 
sequences,  message  priorities,  and  other  functions 

of  the  operating  system  should  be  kept  in  a  central 
file  for  reference  by  network  management,  operators, 
and  engineers. 
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From  the  above  list,  it  can  be  seen  that  statistics  play 
an  important  role  in  network  control  and  management  functions . 
Of  the  12  functions  given,  only  diagnostic  assistance  and 
flow  control  fall  outside  the  realm  of  network  statistics. 
Diagnostic  assistance  is  primarily  a  tech  control  function, 
while  flow  control  is  a  mechanism  to  provide  network 
integrity  during  traffic  surges.  Although  not  part  of  the 
statistical  package,  statistics  should  be  collected  on  these 
functions . 

The  need  for  the  above  statistics  arises  within  an  on¬ 
going  network  management  effort  because  sufficient  information 
must  be  acquired  to  support  necessary  operational  or  economic 
decisions.  Failure  to  collect  statistics  can  have  a  major 
impact  on  the  network;  for  example,  it  can  result  in  an 
ineffective  system;  further,  it  could  also  lead  to  the 
dropping  of  a  system  of  high  potential  value. 

Network  statistical  packages  are  usually  designed  to 
contain  several  layers  of  reports  which  can  be  produced  by 
operator  request.  These  outputs  are  layered  because  the 
amount  and  type  of  reported  statistics  should  depend  upon 
the  volatility  of  network  growth,  with  network  cutover  and 
traffic  surges  requiring  detailed  reports  and  predictable 
network  performance  requiring  summary  reports.  Statistics 
should  never  be  reported  and/or  analyzed  for  their  own  sake. 
Continuing  surveillance  should  be  maintained  over  the  potential 
impact  of  the  reported  statistics  on  network  management 
decisions.  Any  time  it  appears  the  statistics  will  have  no 
effect  on  the  network  management  decisions,  they  should 
be  dropped  from  the  reporting  process. 

The  reporting  of  all  statistics  requires  the  collection 
of  all  statistical  data.  However,  the  layered  reporting 
process  recommended  above  offers  network  designers  a  choice. 
Some  designers  might  require  the  collection  of  detailed  data 
on  the  assumption  that  detailed  reports  for  a  specific  day 
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may  be  requested  on  the  basis  of  the  summary  reports.  Other 
designers  set  flags  in  the  concentrator  and  front  end 
operating  systems  to  allow  statistical  data  to  be  collected 
only  after  a  request  for  a  certain  statistical  report  is 
made.  Many  designers  use  a  combination  of  the  two  approaches. 
In  these  cases,  the  decision  as  into  which  of  the  categories 
certain  data  falls  is  made  on  the  basis  of  the  processing 
overhead  of  collecting  the  data  versus  the  cost  of  not 
always  having  the  data  at  hand.  Finally,  statistical 
packages  should  usually  have  network  performance  limits  incor¬ 
porated  into  them  so  that  exception  reports  can  be  produced 
when  the  limits  are  exceeded.  These  reports  should  then 
trigger  requests  by  management  and  operations  for  more 
detailed  reports. 

2 • 3  Manual  Measurement  Subsystem 

Of  the  10  statically-related  functions  mentioned  in 
Section  2.2,  facility  monitoring  and  correction,  system 
monitoring  and  correction,  and  operational,  traffic,  per¬ 
formance,  and  utilization  statistics  are  functions  of  the 
computerized  measurement  subsystem  of  the  statistical 
package.  These  functions  are  performed  by  computers,  so 
it  is  possible  to  insert  counting  and  recording  loops  into 
the  programs  so  the  computers  will  automatically  perform  the 
statistics  collection  function.  Beyond  this  capability  it 
is  possible  in  certain  cases  to  add  logic  to  the  recording 
loops  so  that  a  sampling  plan  is  implemented  at  the  same 
time.  Thus,  in  these  cases,  the  data  can  be  received  from 
the  computers  in  a  ready-to-analyze  statistical  format. 

System  component  and  location  statistics,  monthly 
cost  statistics,  and  operating  system  characteristics  are 
functions  of  the  manual  measurement  subsystem  of  the  statis¬ 
tical  package.  All  these  statistics  can  be  kept  in  a 
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computerized  data  base;  however,  the  input  for  these  statis¬ 
tics  must  be  manually  entered  into  the  system.  Figures  2.2  - 
2.8  show  sample  forms  that  can  be  used  to  collect  this  infor¬ 
mation.  Figure  2.2  requests  the  data  needed  for  the  monthly 
cost  statistics  and  operating  system  characteristics;  this 
form  gives  an  overview  of  the  network,  showing  where  com¬ 
munications  equipment  and  facilities  are  located,  providing 
the  cost  associated  with  each  component,  and  gathering  docu¬ 
mentation  on  a  network  description.  The  form  shown  in 
Figure  2.3  is  used  to  collect  system  location  statistics, 
while  Figures  2.4  -  2.8  are  used  to  obtain  information  for 
system  component  statistics.  Finally,  it  should  be  noted 
that  Figures  2.4  -  2.8  request  information  on  each  type  of 
network  component,  not  on  each  component  itself.  Let  us  now 
look  at  some  of  these  forms  in  slightly  more  detail. 

2.3.1  Network  Configuration  and  Cost  Summary 

The  Network  Configuration  and  Cost  Summary  form  (Figure 
2.2)  requests  five  types  of  information.  The  first  type  of 
information  is  on  the  network  communication  equipment.  Each 
item  under  this  type  is  assigned  an  identification  number  by 
the  network  control  center  (NCC)  .  The  site  name  at  which  the 
item  is  located  is  given;  this  name  corresponds  to  the  mane 
of  a  site  on  a  Location  Dependent  Data  form.  Each  item  also 
has  a  device  code  assigned  to  it  which  can  be  used  to  find 
the  appropriate  Device  Data  form  for  a  description  of  the 
device.  The  monthly  charges  for  the  item  are  given,  as  is 
the  identification  numbers  of  other  equipment  directly 
connected  to  the  item. 

The  information  requested  for  communication  facilities 
includes  the  equipment  identification  numbers  for  the  end¬ 
points  of  the  facility  segment.  These  numbers  correspond 
to  those  given  above,  so  other  location  data  is  not  needed. 
Facility  code  information  relates  this  segment  to  tariff 
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and  descriptive  data  found  on  a  Facility  Data  form,  while 
the  facility  identification  number  will  be  assigned  to  the 
segment  by  the  NCC.  For  multidrop  lines,  the  same  identi¬ 
fication  number  would  be  used  for  all  segments,  although  the 
facility  codes  could  be  different  for  each  segment.  Finally, 
monthly  charges  are  given  for  each  facility. 

The  name,  business  address,  and  telephone  number  of 
each  person  involved  with  the  running  of  the  network  should 
be  given.  In  addition  to  this  information,  the  function  of 
the  person  in  the  network  should  be  listed.  The  total 
monthly  personnel  costs  should  be  given  in  this  section, 
although  the  salary  of  each  person  must  not  be  present 
(i.e.,  the  Privacy  Act  would  probably  prohibit  it). 

Other  network  costs,  such  as  buildings,  electricity, 
water,  and  taxes,  should  be  included  on  the  form.  Finally 
the  total  monthly  network  cost  should  be  found  on  the  form. 
Descriptive  documentation  on  the  network,  protocols,  etc., 
should  then  be  filed  with  this  form  for  reference  at  a  later 
date. 

2.3.2  Site  Characteristics 


The  information  contained  on  the  Location  Dependent 
Data  forms  (Figure  2.3)  includes  the  name  and  mailing  address 
of  a  network  node  or  site.  In  addition  to  this  information, 
the  network  telephone  numbers  associated  with  the  site  should 
be  given,  as  well  as  a  description  of  for  what  the  telephone 
numbers  are  used.  Finally,  V&H  coordinates  or  latitude  and 
longitude  should  be  given  for  each  site.  This  information 
is  needed  for  network  design  purposes.  If  some  forms  have 
V&H  data  while  others  have  latitude  and  longitude,  a  program 
can  be  run  to  convert  all  data  into  V&H  coordinates.  Thus 
computer  generated  network  designs  are  possible  with  these 
forms . 
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2.3.3  Communication  Devices 


The  five  other  forms  associated  with  the  manual  measure¬ 
ment  subsystem  are  similar  in  nature.  Because  of  this,  we 
will  focus  on  only  one  of  these,  the  Device  Data  form 
(Figure  2.4) .  This  form  contains  a  device  code  which  allows 
a  piece  of  equipment  on  the  Network  Summary  form  to  be  related 
to  it.  The  manufacturer  and  his  designation  of  the  device 
is  given,  as  is  a  functional  keyword  as  to  the  device  type. 

The  number  and  kind  of  terminations  allowed  by  the  device  are 
given,  as  is  the  various  costs  associated  with  the  device. 

A  descriptive  narrative  of  the  device  and  its  function  is 
given;  this  description  could  be  placed  on  a  data  base  along 
with  the  other  device  information.  Finally,  detailed  func¬ 
tional  specifications  and  other  vendor  literature  would  be 
filed  with  the  form  for  future  reference. 

2.3.4  Final  Remarks 


Whether  or  not  the  above  information  is  placed  in  a 
computerized  data  base,  the  forms  containing  the  information 
should  be  stored  in  a  central  file  at  the  NCC  for  reference 
by  management,  operators,  and  engineers.  In  addition,  these 
forms  should  be  updated  as  new  sites,  devices,  personnel, 
and  system  characteristics  are  added.  The  forms  should  be 
signed-out  before  being  removed  from  the  file  and  signed-in 
when  returned.  By  following  these  suggestions  the  manual 
measurement  subsystem,  a  necessary  portion  of  the  network 
statistics,  will  not  be  overlooked. 

The  computerized  measurement  subsystem  envisioned  by 
NAC  for  the  LDCN  is  somewhat  more  complex  than  the  manual 
measurement  subsystem.  In  this  subsystem,  the  type  of 
statistical  reports  for  management,  operators,  and  engineers 
must  be  based  on  the  data  that  can  be  collected  in  the  net¬ 
work  and  massaged  by  algorithms  run  on  an  Interdata  7/32. 
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Because  of  this  complexity,  the  next  three  sections  of  the 
report  deal  with  the  computerized  measurement  subsystem. 
Section  3  discusses  the  design  of  statistical  reports  pro¬ 
posed  for  the  LDCN,  while  Section  4  considers  possible  data 
measurement  mechanises.  Finally,  Section  5  focuses  on  a 
processing  methodology  needed  to  convert  the  data  collected 
in  Section  4  to  the  reports  of  Section  3. 
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1.  Capacity  Analysis  of  Data  Communication  Concentrators, 

NAC  Report  FR.043.01R,  Network  Analysis  Corporation, 

Glen  Cove,  New  York 

2.  Feasibility  Analysis  of  PDP-11  Minicomputer  Front  End 
Processor,  NAC  Report  FR.060.01,  Network  Analysis 
Corporation,  Glen  Cove,  New  York 

3.  Configuration  Designs  for  LDCN  Communication  Processors, 
NAC  Report  FR.095.01R,  Network  Analysis  Corporation, 

Glen  Cove,  New  York 

4.  LDC  Design  Group  Meeting  Memorandum  10462/3-1,  dated 
19  March  1976 

5.  LDCN  Sign-on/Sign-off  Procedures,  draft  copy  of  memorandum 
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DOCUMENTS  CONCERNING  THE  LDCN 
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LDCN  NETWORK 


.  Communication  Equipment 


_ Monthly  Charges 

Device,  Host,  or  Lease  or 

Eg.  ID  Site  Name  Terminal  Code  Amort lzat ion  Maintenance  Connects  to  Eg.  ID(s) 

1. 

2. 


3. 


2.  Communication  Facilities 

_ Endpoints _  _ Monthly  Charges _ 

Eg.  ID  1  Eg.  ID  2  Facility  Code  Facility  ID*  Line  Drop  &  Termination 


3.  Communication  Personnel 

Name  Address 


Telephone  Function 


_  Total  Personnel  Costs: 

A.  Other  Costs 

m.  Building _ 

Electricity  _ 

Total  _ 

*.  5.  Attach  documents  describing  the  network,  protocols,  etc.,  to  this  sheet 


*  For  multidrop  lines  list  all  branches  using  the  same  ID 


Figure  2.2:  NETWORK  CONFIGURATION  AND  COST  SUMMARY 
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SITE  CHARACTERISTICS 


1.  NAME  __ _ 

2.  ADDRESS  _ 

3.  CITY  _ _ ■ 

A.  STATE  . _ 

5.  ZIP  _ _ 

6.  AREA  CODE  AND  TELEPHONE  NUMBER(S) 

7 .  LONGITUDE _ _ 

8.  LATITUDE _ _ 

9.  V  COORDINATE  _ 

10.  H  COORDINATE  _ 


Figure  2.3:  FORM  FOR  LOCATION  DEPENDENT  DATA 
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COMMUNICATION  DEVICES* 

1.  Device  Code  _ _ 

2.  Manufacturer's  Type  or  Part  No.  _ 

3.  Manufacturer  _ 

4.  Device  Type  (Concentrator,  Multiplexer,  Terminal  Controller,  Front 

End)  _ 

5.  Terminations 

Number  Allowable  Terminals  Allowable  Facilities  Speed(s) 

(Terminal  Codes)  (Facility  Codes) 


6.  Costs 

Purchase:  _  Lease:  _  Installation: 

Maintenance:  _ 

7.  Device  Function  (Narrative): 


8.  Attach  functional  specifications  and  other  documents  for  this  device 
to  this  sheet. 


*  Excluding  terminals  and  hosts 

Figure  2.4:  FORM  FOR  COMMUNICATION  DEVICE  DATA 
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MODEMS  AND  LINE  TERMINATION  EQUIPMENT 


1 .  Device  Code 


2.  Manufacturers  Type  or  Part  Number 


3.  Manufacturer 


4.  Modulation  Method 


5.  Compatibility  with  Bell 


6.  Channel  Speed (s)  _ 

7.  Leased  Line/Dial  Up 

8.  Multiport  Class  _ 

9.  Costs 

Purchase :  _ 

Maintenance : 


Lease : 


Installation: 


10.  Attach  functional  specifications  and  other  documents  for  this  device 
to  this  sheet. 


Figure  2.5:  FORM  FOR  DATA  ON  MODEMS  AND  LINE  TERMINATION  EQUIPMENT 
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HOST  CHARACTERISTICS 

1 .  Host  Code  _ _ 

2.  Manufacturers  Type  or  Part  Number  _ 

3.  Manufacturer  _ _ 

4.  Allowable  Communications  Access  Modes  _ 

Speed  Asynch /Synch 


5.  Polling  Disciplines _ _ _ _ 

6.  Costs 

Purchase:  _  Lease:  _  Installation:  _  Maintenance: 

7.  Host  Functions  (Narrative) 


8.  Attach  functional  specifications  and  other  documents  for  this  device 
to  this  sheet. 


Figure  2.6: 


FORM  FOR  HOST  DATA 
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Terminal  Characteristics 

1.  Terminal  Code  _ 

2.  Manufacturer's  Type  or  Part  No.  _ 

3.  Manufacturer  _ 

4.  Asynchronous  or  synchronous  _ _ _ 

5.  Buffer  size  (0  if  unbuffered)  _ 

6.  Allowable  Transmission  Speeds  _ 

7.  Allowable  Reception  Speeds  _ 

8.  Hard  copy/CRT  or  both  _ 

9.  Polled/Unpolled  _ 

10.  Code  Osed  (Baudot,  ASCII,  EBCDIC) _ 

11.  MTBF,  MTR _ ,  _ 

12.  Half /Full  Duplex  or  both  _ 

13.  Costs 

Purchase:  _  Lease:  _  Installation:  _ Maintenance:  _ 

14.  Attach  functional  specifications  and  other  documents  for  this  device 
to  this  sheet. 


Figure  2.7:  FORM  FOR  TERMINAL  DATA 
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COMMUNICATION  FACILITY  CHARACTERISTICS 


1 .  Facility  Code 


2.  Tariff  or  Vendor  ID 


3.  Vendor  or  Source 


4.  Mode  (Packet,  Digital,  Analog) 


5.  Tarrif  Cost  Structure 


6.  Bit  Error  Rate 


Modem  Code 


8.  Attach  functional  specifications  and  other  documents  for  this  device 
to  this  sheet. 


Figure  2.8:  FORM  FOR  DATA  ON  COMMUNICATION  FACILITIES 
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3.  REPORT  DESIGN 


This  section  describes  the  management,  operation  and 
engineering  reports  proposed  by  NAC  for  the  computerized 
measurement  subsystem  of  the  LDCN's  statistical  package. 

The  data  in  each  report  is  based  on  the  functions  of  the 
persons  receiving  the  report.  Thus  management  reports 
would  be  produced  off-line  and  contain  summary  data  on  net¬ 
work  performance  and  traffic  characteristics,  while  operations 
would  obtain  more  detailed  network  summary  reports  in  addition 
to  on-line  reports  of  network  status.  Engineering  reports 
would  contain  detailed  statistics  on  each  aspect  of  the  net¬ 
work's  performance;  these  reports  would  be  used  for  network 
troubleshooting  and  debugging.  In  addition,  management  and 
operations  would  receive  exception  reports  when  system  per¬ 
formance  limits  were  exceeded. 

The  statistical  contents  of  each  report  reflect  the  needs 
of  each  level  of  personnel  in  the  network  hierarchy.  Net¬ 
work  managers  are  generally  interested  in  whether  the  over¬ 
all  system  performance  is  within  limits,  the  amount  of 
traffic  supported  by  tae  network,  and  the  growth  of  the  net¬ 
work  since  cutover.  In  addition,  management  must  be  informed 
about  potential  system  bottlenecks  or  inadequate  system 
performance,  as  they  are  ultimately  responsible  for  the 
running  of  the  network.  Summary  network  reports  thus  serve 
the  basic  need  of  management  while  exception  reports  guarantee 
management  of  information  on  potential  or  real  system  problems. 
On  the  next  level,  the  personnel  in  operations  need  real¬ 
time  network  statistics  so  they  can  take  immediate  action  on 
failed  components  and  network  bottlenecks.  In  addition, 
operations  require  a  more  detailed  summary  of  the  network 
performance  so  they  can  follow,  predict,  and  correct  potential 
bottlenecks  before  they  occur.  Finally,  on  the  lowest  level, 
engineering  reports  present  the  most  detailed  statistics  of 
all  reports.  These  reports  are  used  to  reconstruct  the 
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conditions  under  which  a  system  failure  occurred  or  to  shed 
light  on  questions  raised  by  the  management  and  operations 
reports.  Due  to  the  level  of  detail,  engineering  reports 
are  usually  quite  large;  because  of  this,  the  reports  may 
be  periodically  produced  over  a  greater  time  interval  than 
management  and  operations  reports  (e.g.,  once  a  month  rather 
than  once  a  week) ,  or  upon  request  for  specific  data. 

Before  describing  the  statistical  reports,  two  topics 
are  discussed.  First,  the  rules  for  effective  presentation 
of  data  in  tables  and  graphs  are  reviewed  in  Section  3.1. 

Many  of  these  are  common  sense  rules  followed  in  the  normal 
course  of  preparing  tables  and  graphs;  however,  this  section 
is  envisioned  as  a  reference  for  the  FMSO  design  team  when 
it  develops  the  LDCN  statistical  package.  Second,  an 
overview  of  the  data  proposed  for  gathering  for  the  LDCN 
statistics  is  given  in  Section  3.2  so  that  the  statistics 
described  in  the  reports  that  follow  can  be  mapped  into  the 
overall  picture.  After  this,  the  various  reports  are 
described . 

3.1  Rules  for  Preparing  Tables  and  Graphs 


In  the  course  of  developing  proposed  reports  for  FMSO 
consideration,  NAC  recognized  that  some  fraction  of  the  reports 
would  not  fulfill  FMSO's  needs.  This  fraction  of  reports 
would  contain  those  with  too  much  data,  with  too  little  data, 
with  the  wrong  type  of  data,  and  with  the  wrong  report  format. 
NAC  also  recognized  that  because  of  this,  FMSO  personnel 
would  have  to  design  statistical  reports  for  the  LDCN.  To 
aid  the  design  team  in  developing  the  actual  report  formats, 
the  current  section  on  preparing  tables  and  graphs  is  given. 

The  material  given  in  this  section  is  not  new.  The  rules 
presented  here  were  learned  by  the  author  when  he  attended  an 
in-house  seminar  while  working  at  Bell  Laboratories  in  1973. 
Figures  3.3,  3.6,  and  3.7  were  from  a  handout  given  at  that 
seminar. 
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3.1.1  Tables 


In  the  outputting  of  statistical  tables ,  care  should  be 
taken  to  format  the  data  so  it  will  be  useful  to  the  persons 
reading  the  tables.  If  the  table  is  not  easy  to  read  and/or 
the  information  being  presented  is  not  discernable,  the  table 
has  failed  its  purpose.  An  example  of  this  is  shown  in 
Figure  3.1,  which  presents  a  typical  list  from  a  computerized 
data  base.  After  looking  at  Figure  3.1,  one  might  assume  the 
first  column  represented  locations  while  the  other  columns 
were  V&H  coordinates;  however,  one  has  no  quick  way  of 
verifying  this  assumption  or  of  knowing  what  the  locations 
represent.  Figure  3.2  shows  the  same  type  of  data  after 
formatting.  In  this  figure  the  locations  and  V&H  coordinates 
are  spelled  out;  further,  one  knows  the  data  in  the  table 
represents  potential  new  terminal  sites  by  1978.  The  differ¬ 
ence  due  to  formatting  is  dramatic;  Figure  3.2  has  been  used 
in  presentations  and  briefings  of  its  network,  while  Figure 
3.1  was  not  used  for  this  purpose. 

In  order  to  format  data  into  tables,  one  must  know  the 
basic  parts  of  a  statistical  table.  These  basic  parts  are 
illustrated  in  Figure  3.3: 

a.  The  "title"  should  list  such  important  factors  as 
the  type  of  material  presented,  its  classification, 
the  georgaphic  region  to  which  it  refers,  and  the 
period  covered.  Titles  should  not  be  excessively 
long;  so  when  a  substantial  amount  of  information 
must  be  given,  sub-titles  should  be  used  to  elaborate 
on  the  title. 

b.  The  "prefatory  note"  describes  the  figures  in  the 
table,  including  the  units  represented  by  the  figures 
and  any  special  characteristics  or  limitations  of 
the  data. 
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c.  The  "caption"  (column  headings)  and  the  "stub"  (row 
identification  -  usually  on  the  left)  should  be 
clear  and  very  concise. 

d.  The  "unit  of  measurement"  is  used  in  the  caption  or 
stub  as  needed.  It  is  not  needed  in  Figure  3.3; 
however,  if  there  were  several  different  columns 

of  data,  the  units  of  measurement  would  be  inserted 
for  each  column.  In  this  case,  the  prefatory  note 
would  be  made  more  general  or  eliminated. 

e.  The  "body"  of  the  table  contains  the  rows  and  columns 
of  actual  data.  The  body  should  be  spaced  or  divided 
by  rulings  so  that  each  data  item  can  be  conveniently 
found. 

f.  The  "footnote"  is  used  to  explain  some  specific  part 
of  the  table.  It  is  placed  immediately  beneath  the 
table  and  above  any  source  note.  Each  footnote  should 
be  indicated  by  a  symbol .  Letters  may  be  used  to 
indicate  footnotes  only  if  there  is  no  chance  of 
mistaking  them  for  data;  for  this  reason,  numbers 
should  never  be  used  to  indicate  footnotes. 

g.  The  "source  note"  is  placed  at  the  bottom  of  the 
table.  Source  notes  should  give  the  primary  source 
of  data  along  with  the  place  where  the  data  was 
actually  found,  if  the  two  should  be  different. 

Source  information  should  include:  Author,  Title, 
Volume,  Series,  Page,  Publisher,  Place  of  Publication, 
and  Date.  Source  notes  are  usually  not  found  in 
computer-generated  tables. 

Careful  arrangement  of  a  table  facilitates  reading, 
analysis,  and  comparison  of  data.  Further,  items  can  be 
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arranged  to  emphasize  selected  elements  or  specific  aspects 
of  data.  The  following  are  possible  ways  to  arrange  data  in 
a  table: 


a.  Alphabetically  according  to  item  name.  This  is  the 
most  frequently  used  data  arrangement  in  general- 
purpose  tables. 

b.  Chronologically  according  to  the  time  of  occurrence. 
Dates  are  arranged  from  the  earliest  to  the  latest 
and  positioned  so  they  move  down  the  stub  or  across 
the  captions  from  left  to  right. 

c.  Geographically  according  to  a  customary  classifi¬ 
cation  such  as  country,  state,  county;  or  according 
to  any  customary  listing  such  as  cities  by  state 
region . 


d.  Magnitude  according  to  some  aspect  of  size.  The 
largest  or  the  smallest  number  is  placed  at  the  top 
of  the  column  while  the  others  are  arranged  in 
descending  or  ascending  order,  as  required. 
Similarly,  caption  rows  are  arranged  in  the  same 
manner,  from  left  to  right. 

e.  By  customary  classification,  as  in  the  case  of  non¬ 
serial  data.  For  example,  men,  women,  and  children 
are  rarely  listed  in  any  other  order. 


As  effective  as  a  properly  designed  statistical  table 
can  be,  a  graph  can  be  a  more  interesting  and  effective 
device  for  recording  and  illustrating  the  essential  features 
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of  a  set  of  data  and  for  pointing  out  the  conclusions  that 
can  be  drawn.  For  this  reason,  extensive  use  is  made  of  such 
devices  in  presenting  information  to  management  or  super¬ 
visory  people  who  need  a  quick  grasp  of  a  broad  situation. 
Unfortunately,  the  graphics  capability  of  many  printers 
leave  much  to  be  desired.  Figure  3.4  shows  a  sample  graphic 
output  from  a  printer.  The  minimum  and  maximum  values  of 
X  and  Y  are  given,  and  the  lower  and  upper  values  of  Y  are 
listed  in  the  two  columns  next  to  the  graph.  However,  the 
graph  has  to  be  rotated  90  degrees  counterclockwise  to 
obtain  the  proper  perspective  of  the  graph.  Because  of 
this  and  other  inadequacies ,  .  many  operation  groups  have  an 
aide  who  will  plot  graphs  from  the  data  given  them.  Figure 
3.5  is  a  sample  of  such  a  graph. 

Because  the  purpose  of  all  graphs  is  to  convey  certain 
information  quickly  and  effectively,  they  must  be  kept  as 
simple  as  possible.  The  natural  tendency  to  include  addi¬ 
tional  material  must  be  resisted  or  the  result  will  be 
complex  presentations  that  defeat  the  basic  purpose.  Further, 
since  graphs  tend  to  catch  the  eye  of  the  reader,  they  are 
often  read  out  of  context,  making  it  extremely  important 
that  each  one  be  complete  and  self-contained  so  the  casual 
reader  will  still  get  the  true  meaning  of  the  data  presented. 
This  is  also  important  because  of  the  tendency  to  use  graphs 
out  of  context  in  speeches,  special  presentations,  and 
technical  papers. 

The  rules  for  graphs  are  similar  to  those  cited  for  data 
tables.  But  since  there  are  slight  differences,  applicable 
rules  for  graphs  are  best  reviewed  in  full.  These  include: 

a.  Every  graph  (see  sample  in  Figure  3.6)  should  have 
a  clear  and  concise  title  which  includes  information 
about  the  type  of  the  data,  the  geographical 
location,  and  the  period  covered.  The  title 
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usually  appears  below  printed  graphs;  otherwise,  it 
is  customary  to  put  it  at  the  top. 

b.  Coordinate  lines  should  be  held  to  a  minimum,  while 
the  curves  should  stand  out  sharply  against  the 
background. 

c.  To  increase  understanding,  the  curves  should  be  as  few 
in  number  as  possible,  and  each  should  stand  out 
clearly.  To  do  this,  different  symbols  should  be 
used  for  each  curve. 

d.  Any  footnotes  should  be  placed  under  the  lower-left 
of  the  graph. 

e.  If  the  data  is  not  obtained  from  a  computer,  its 
source  should  be  under  the  lower-left  corner  of  the 
graph,  below  any  footnotes. 

f.  Scales  of  values  should  be  placed  along  the  X-  and 
Y-axis  to  give  a  general  indication  of  the  sizes 
represented  on  the  graph.  Fine  graduations  are 
unnecessary,  since  it  is  not  intended  that  actual 
values  will  be  read  from  a  graph.  Such  values  are 
obtained  from  the  tables  which  should  also  be  part 
of  the  output. 

g.  Time  measurements  are  customarily  put  on  the  X-axis. 

h.  On  the  Y-axis,  the  values  should  run  from  zero  (or 
the  smallest  value)  at  the  bottom  of  the  graph  to 
the  highest  value  at  the  top.  On  the  X-axis,  the 
values  should  run  from  the  lowest  on  the  left  to 
the  highest  on  the  right. 
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i.  Each  axis  should  have  its  own  caption  to  specify  the 
units  used  unless  they  are  completely  obvious.  The 
X-axis  caption  should  be  centered  directly  beneath 
the  X-axis,  while  the  Y-axis  caption  should  be  placed 
at  the  top  of  the  Y-axis. 

j .  The  zero  point  should  usually  be  included  on  the 
Y-axis.  If  it  is  not,  the  graph  can  be  misleading 
in  the  apparent  relationships  of  the  data  it 
presents  (Figure  3.7).  Note  how  inclusion  of  the 
zero  point  on  the  Y-axis  in  Graph  2  of  Figure  3.7 
indicates  an  entirely  different  ratio  between  the 
highs  and  lows. 

If  lack  of  space  makes  it  inconvenient  to  use  a  zero 
point,  a  scale  break  can  be  inserted  to  signal  the 
reader  that  a  portion  of  the  scale  has  been  omitted. 

k.  If  spaces  on  the  X-axis  are  used  to  indicate  a  time 
interval ,  the  value  for  each  period  should  be  plotted 
at  the  midpoint  of  the  interval  (Figure  3.7).  If 
the  periods  coincide  with  the  coordinate  lines,  the 
points  are  plotted  on  the  coordinates. 

By  following  these  simple  rules,  the  tables  and  graphs 
of  the  network  statistical  package  will  convey  their  infor¬ 
mation  quickly  and  effectively. 

3 . 2  Overview  of  Proposed  LDCN  Data 

In  reading  the  following  sections  of  the  study,  one 
might  wonder  what  methodology  was  used  by  NAC  to  arrive  at 
the  proposed  reports  and  data  collection  mechanisms.  Basically, 
a  listing  of  the  possible  statistics  for  communication 
networks  was  first  created.  The  data  needed  to  produce  these 
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statistics  was  then  determined.  NAC's  understanding  of  the 
LDCN  was  then  used  to  determine  which  of  this  data  could  be 
straightforwardly  collected  by  the  LDCN.  From  this  informa¬ 
tion,  NAC  developed  a  set  of  "proposed  statistics"  for  the 
LDCN.  Finally,  the  proposed  reports  were  developed  based  on 
the  proposed  statistics. 

When  FMSO  designs  the  LDCN  statistical  package,  it  should 
follow  a  similar  methodology.  Listings  of  possible  network 
statistics  and  the  data  needed  to  produce  them  can  be  created 
from  the  information  found  in  this  report,  the  NAC  documents 
listed  in  Table  2.1,  and  NAC  document  FR.095.02  -  Simulation 
Specification  for  Modelling  the  Logistics  Data  Communication 
Network.  Having  mentioned  this,  let  us  now  briefly  look  at 
the  data  NAC  proposes  for  collection  by  the  LDCN. 

The  proposed  data  falls  into  seven  broad  categories. 

The  first  category  is  data  for  System  Configuration  Statistics. 
In  this  group  falls  such  data  as  the  number  of  users  on  the 
system  at  any  given  time  and  their  connectivity  in  the  net¬ 
work  (i.e.,  concentrator,  front  end,  and  system  being  accessed). 
Also  in  this  category  is  data  on  host,  front  end,  concentrator, 
and  line  status,  such  as  start-up,  shut-down,  failure,  and 
restoral  reports.  Such  reports  can  be  used  by  management  to 
see  if  the  contracted  network  reliability  figures  are  being 
met . 

The  second  set  of  data  is  for  Traffic  Statistics.  This 
data  centers  around  the  ability  of  the  front  ends  to  capture 
information  on  message  arrival  times,  source  and  destination 
information,  and  message  type  information  (i.e.,  terminal- 
terminal,  broadcast,  inquiry,  upquiry,  batch,  real-time,  and/ 
or  AUTODIN  traffic) .  This  same  data  is  needed  for  Message 
Statistics;  in  addition,  message  input  and  output  length 
data  is  collected. 

The  data  proposed  for  Response  Time  Statistics  can  be 
divided  into  those  collected  at  the  concentrators  and  those 
collected  at  the  front  ends.  At  the  front  ends,  time  and 
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date  information  is  collected  when  the  last  segment  of  an  input 
is  successfully  received,  when  the  first  segment  of  a  real-time 
input  message  is  placed  on  an  output  queue,  and  when  the  output 
buffer  for  the  last  segment  of  a  real-time  input  message  is 
released.  Output  timings  are  taken  when  the  first  segment  is 
successfully  received,  when  the  first  segment  is  placed  on  an 
output  queue,  and  when  the  output  buffer  for  the  first  output 
segment  is  released.  These  values  allow  determination  of  front 
end  processing  times,  host  processing  times,  and  queuing  and 
transmission  times  experienced  by  segments  leaving  the  front 
ends.  In  addition  to  this  data,  an  indication  of  when  an 
output  message  is  blocked  from  immediate  delivery  should  be 
recorded.  Finally,  concentrators  should  be  able  to  collect 
information  on  their  average  processing  time  of  a  segment,  and 
on  the  queuing  and  transmission  times  of  input  segments  to 
the  front  ends.  This  data  will  then  allow  response  time  - 
throughput  calculations  for  real-time  messages. 

Utilization  Statistics  include  CPU,  disk,  buffer,  line, 
and  core  utilization.  Core  utilization  data  is  on  the  border¬ 
line  between  the  manual  and  computerized  measurement  sub¬ 
system.  This  data  is  obtained  from  a  core  map;  however,  the 
data  need  only  be  collected  as  new  programs  or  buffer  require¬ 
ments  are  added  to  the  system.  Line  utilization  statistics 
can  be  determined  from  the  data  collected  for  System  Config¬ 
uration,  Message  Length,  and  Traffic  Statistics.  CPU,  disk, 
and  buffer  utilization  data  depends  upon  the  approach  chosen 
by  the  system  implementors,  since  both  hardware  and  soft¬ 
ware  monitoring  is  possible.  Because  of  this,  NAC  does  not 
recommend  an  approach  for  collecting  this  data;  however,  we 
do  recommend  that  the  data  be  collected. 

The  data  for  Queue  Statistics  could  be  obtained  by 
either  keeping  track  of  the  time  each  item  is  on  queue,  or  by 
sampling  the  queue  length  each  N  milliseconds.  For  heavily 
loaded  systems,  the  latter  approach  is  more  efficient.  The 
former  approach  is  more  accurate;  in  addition,  for  lightly 
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loaded  systems,  it  may  be  argued  to  be  more  efficient.  NAC 
proposes  initially  implementing  the  latter  approach.  In 
addition  to  this  data,  the  LDCN  should  collect  data  on  whether 
a  batch  queue  leaves  the  front  end  because  of  time  or  size 
criteria,  as  well  as  the  number  of  entries  in  the  queue. 

Finally,  data  for  Error  Statistics  should  be  collected. 

This  data  includes  line  error  reports,  concentrator  and  front 
end  congestion  reports,  queue  overflow  reports,  and  other 
miscellaneous  reports.  NAC  feels  the  data  for  these  reports 
is  readily  available  for  collection  by  the  front  ends. 

Figure  3.8  is  a  summary  of  the  data  proposed  for  collection 
by  the  LDCN.  After  reviewing  this  report  and  determining 
what  data  will  be  collected  by  the  LDCN,  FMSO  personnel 
should  create  a  similar  figure  for  their  own  use  and  for 
documentation  purposes . 

3.3  Proposed  Reports 

This  section  describes  the  reports  proposed  by  NAC  for 
the  LDCN  computerized  statistical  package.  Section  3.3.1 
describes  the  core  utilization  report,  which  is  included  in 
the  computerized  subsystem  only  because  data  from  a  computer's 
core  map  is  required.  Section  3.3.2  reviews  the  three  weekly 
summary  reports  and  one  exception  report  that  should  be 
received  by  management.  In  addition  to  these  reports, 
personnel  in  operations  should  receive  real-time,  on-line 
reports,  two  additional  weekly  summary  reports,  and  eight 
additional  exception  reports.  Section  3.3.3  describes  these 
operational  reports.  Section  3.3.4  discusses  30  possible 
engineering  reports,  telling  when  and  where  they  may  be  used. 
Finally,  Section  3.3.5  indicates  an  implementation  schedule 
and  the  relative  importance  of  each  of  the  above  reports. 
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3.3.1  Core  Utilization  Report 

Figure  3.9  shows  the  proposed  output  for  the  core  uti¬ 
lization  report.  The  date  the  report  is  produced  is  given, 
as  well  as  the  concentrator  or  front  end  referred  to  by  the 
report.  Each  entry  in  the  report  contains  a  program  or 
storage  identifier,  the  start  and  end  values  of  the  region 
it  uses,  and  the  region  size  in  bytes.  Core  utilization 
reports  should  be  produced  only  after  changes  are  implemented 
to  programs  and  storages  in  the  communication  devices.  After 
being  produced,  these  reports  should  be  filed  behind  the 
Configuration  Report  of  the  manual  measurement  subsystem. 
Because  of  these  facts,  core  utilization  reports  are  said 
to  be  on  the  borderline  between  the  manual  and  computerized 
measurement  subsystems. 

3.3.2  Management  Reports 

The  theory  behind  management  reports  is  to  supply 
enough  useful  information  so  that  a  system  can  be  tracked, 
but  not  too  much  information  so  that  those  reports  will  be 
read.  In  addition,  system  status  exception  reports  are 
needed  so  management  is  made  aware  of  major  system  problems 
and  can  bring  its  weight  to  bear  on  the  solution.  To  fill 
this  bill,  the  weekly  summary  reports  of  Figures  3.10-3.12 
are  proposed,  as  is  the  system  status  exception  report  of 
Figure  3.13. 

Figure  3.10  presents  the  summary  statistics  needed  to 
track  the  system.  User,  Traffic,  and  Response  Time  Statis¬ 
tics  are  given  for  the  whole  LDCN  and  for  the  ASO  and  SPCC 
subsystems,  while  Message  Length  Statistics  are  only  given 
for  the  whole  LDCN.  The  User  Section  of  the  report  gives 
the  total  number  of  logons  during  the  week,  and  the  average 
number  of  users  per  hour  during  some  prime-time  period 
defined  by  LDCN  management.  By  using  only  a  prime-time 
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period  in  this  and  other  reports,  a  more  accurate  picture  of 
average  utilization  is  seen,  since  lowly-utilized,  oif-peax 
hours  are  excluded  from  the  average.  The  Traffic  Section  of 
the  report  gives  the  total  number  of  messages  for  the  week 
and  the  average  number  of  messages  per  hour  during  the  prime¬ 
time  period,  in  addition,  the  traffic  data  is  given  for  each 
message  type  so  that  an  accurate  model  of  the  traffic  can  be 
obtained.  The  Response  Time  Section  of  the  report  gives  the 
average  time  from  successful  reception  of  the  last  buffer 
of  input  into  the  concentrator  until  the  first  segment  of 
the  output  is  on  queue  for  output  by  the  concentrator.  This 
response  time  corresponds  to  the  traffic  level  shown  for 
real-time  messages  per  hour  in  the  traffic  section,  so  that 
a  simulation  model  could  be  calibrated  with  the  real  system. 
Finally,  the  Message  Length  Section  of  the  report  gives  the 
mean,  standard  deviation,  and  maximum  character  lengths  for 
the  inputs  and  outputs  of  each  message  type. 

The  Traffic  Summary  Plots  of  Figures  3.11-3.12  are  used 
to  show  the  traffic  growth  of  the  system  for  up  to  two  years. 
Figure  3.11  is  a  plot  for  total  messages  per  week,  while 
Figure  3.12  is  a  plot  for  the  average  number  of  messages 
per  hour  per  week.  Both  reports  would  show  seasonal  trends 
and  as  such  only  one  or  the  other  need  be  produced;  however, 
by  comparing  the  relative  slopes  of  each  graph,  one  could 
determine  if  the  daily  time  interval  for  "average  number  per 
hour"  should  be  increased  to  pick  up  an  increase  in  off- 
hours"  traffic.  Both  reports  could  be  produced  on  a  weekly 
basis;  however,  LDCN  management  could  just  as  easily  receive 
one  plot  weekly  and  the  other  plot  on  a  quarterly  basis. 

The  System  Status  Exception  Report  is  printed  on  a  weekly 
basis  only  if  some  system  component  was  unavailable  for  a 
period  of  time  longer  than  the  performance  limit  set  for  it. 
The  report  lists  the  component,  the  times  it  was  unavailable 
on  a  given  day,  the  reasons  it  was  unavailable,  and  its 
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performance  limit.  By  having  this  report,  management  would 
be  alerted  to  major  system  problems,  so  they  could  use  their 
position  to  help  correct  them. 

3.3.3  Operational  Reports 


Operational  personnel  are  involved  with  the  everyday 
running  of  the  system.  Thus,  in  addition  to  receiving  the 
managerial  reports,  operational  personnel  need  on-line  out¬ 
puts  to  handle  real-time  system  problems.  Four  on-line 
reports  are  proposed  for  the  LDCN.  The  first  is  a  System 
Status  Update  (Figure  3.14a)  printed  whenever  a  system  com¬ 
ponent  becomes  available  or  unavailable.  Along  with  the 
Buffer  and  Queue  Overflow  Update  (Figure  3.14b)  and  the 
Excessive  Line  Error  Update  (Figure  3.14c),  the  System  Status 
Update  allows  operations  to  reconfigure  the  network  to 
temporarily  solve  system  problems.  The  final  on-line  report 
is  Invalid  Password  Update  (Figure  3.14d) ,  printed  whenever 
an  attempted  entry  to  the  system  by  terminal  id  XXXX  fails 
because  of  three  invalid  password  attempts.  All  four  on¬ 
line  reports  will  be  printed  at  the  LDCN  network  control 
center  console. 

To  further  aid  operational  personnel  in  the  performance 
of  their  job,  two  additional  weekly  summary  reports  and 
eight  exception  reports  are  proposed.  The  LDCN  CPU  Utili¬ 
zation  Summary  Report  (Figure  3.15)  gives  the  average  utili¬ 
zation  during  prime-time  for  each  LDCN  concentrator  and  front 
end.  Along  with  the  LDCN  Status  Summary  Report,  this  report 
would  allow  operations  to  correlate  CPU  utilization  growth 
with  LDCN  traffic  growth  and  determine  when  processors  would 
become  saturated.  The  System  Status  Report  (Figure  3.16)  is 
a  summary  of  the  on-line  System  Status  Update  Reports  which 
would  allow  operations  to  determine  what  equipment  should 
be  replaced.  In  addition,  the  System  Status  Report  indicates 
whether  Manual  or  Automatic  Intervention  was  used  to  accom¬ 
plish  a  given  action. 
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The  Buffer  Usage  Exception  Report  (Figure  3.17)  and  the 
Output  Queue  Exception  Report  (Figure  3.18)  give  a  summary 
of  the  on-line  Buffer  and  Queue  Overflow  Update  Reports. 

These  reports  also  list  buffer  pools  and  queues  whose  lengths 
exceeded  a  warning  limit  but  did  not  overflow.  The  maximum 
length  observed,  the  maximum  length  before  overflow,  and  the 
warning  limit  would  also  be  reported. 

The  Line  Notification  Report  (Figure  3.19)  summarizes 
the  on-line  Excessive  Error  Update  Reports  on  a  line  identi¬ 
fication  basis,  while  the  Password  Failure  Report  (Figure  3.20) 
summarizes  the  on-line  Invalid  Password  Update  Reports  on  a 
terminal  identifier  basis.  These  exception  reports  would 
allow  operations  to  determine  whether  certain  line  and  access 
problems  are  transient  or  chronic;  once  this  determination 
was  made,  appropriate  action  could  be  taken. 

The  Line  Utilization  Exception  Report  (Figure  3.21) ,  the 
CPU  Utilization  Exception  Report  (Figure  3.22),  and  the  Disk 
Utilization  Exception  Report  (Figure  3.23)  would  be  printed 
whenever  the  hourly  utilization  of  a  line,  CPU,  or  disk 
exceeds  its  specified  utilization  performance  limit.  The 
component  identifier  is  given,  as  well  as  the  date  and  time 
the  limit  was  exceeded.  Also  given  is  the  component's 
observed  utilization  and  performance  limit.  The  Congestion 
Report  (Figure  3.24)  lists  the  number  of  times  a  concentrator 
or  front  end  had  to  stop  receiving  traffic  because  of 
internal  congestion.  In  addition,  the  average  "congestion 
interval"  observed  for  each  component  is  given.  These  four 
exception  reports  would  allow  operations  to  make  adjustments 
to  the  network  before  the  reported  minor  problems  became 
major  ones. 

3 . 4  Engineering  Reports 


reports  is  to  provide  detailed 
management  and  operational 
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reports.  To  this  end,  thirty  engineering  reports  in  six 
different  areas  are  proposed  for  consideration  by  FMSO  personnel. 
It  is  expected  that  only  a  fraction  of  these  reports  would  be 
implemented;  however,  all  are  listed  to  allow  FMSO  to  make  the 
final  decision  for  implementation. 

3.4.1  User  Statistics 


The  User  Statistics  Engineering  Reports  consist  of  five 
documents.  The  basic  report  is  the  LDCN  User  Status  Report 
(Figure  3.25) ,  which  lists  on  a  daily  basis  the  total  number 
of  logons,  average  number  of  users  per  hour  over  prime  time, 
average  number  of  users  per  peak  hour,  and  the  hour  during 
which  the  peak  occurred.  These  statistics  are  given  for  the 
LDCN  network,  and  for  the  ASO  and  SPCC  systems.  The  User 
Status  Report  by  System  (Figure  3.26)  would  allow  the  data 
for  the  user  status  report  to  be  filtered  by  System  and 
Concentrator  before  being  reported.  User  Status  Plots 
(Figure  3.27)  show  the  average  number  of  users  over  15 
minute  intervals  for  .a  given  dax*_  zThe  User  Status  Reports 
could  be  used  to  observe  the  daily  effects  of  a  system  cut¬ 
over;  this  is  probably  the  only  time  when  either  report  would 
be  requested.  However,  User  Status  Plots  for  the  entire 
LDCN  should  be  produced  after  each  system  cutover  or  every 
six  months,  as  this  report  would  allow  operations  and  manage¬ 
ment  to  see  the  distribution  of  users  over  a  day  as  the  net¬ 
work  grows. 

The  System  Configuration  Report  (Figure  3.28)  is  the 
fourth  report  on  user  statistics.  This  document  gives  a 
snapshot  of  the  LDCN  at  a  given  minute,  and  shows  the  con¬ 
nectivity  of  users  in  the  network  at  that  minute.  Conversely, 
the  System  Signon-Signof f  Report  (Figure  3.29)  gives  the 
connectivity  of  users  over  an  entire  day.  The  System  Config¬ 
uration  Report  would  be  shorter  than  the  Signon-Signof f  Report; 
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however,  both  reports  would  probably  be  used  only  for 
debugging  purposes.  As  such,  these  reports  should  be  imple¬ 
mented  last,  if  at  all. 

3.4.2  Traffic  Statistics 


The  Traffic  Statistics  Engineering  Reports  would  also 
consist  of  five  documents.  The  LDCN  Traffic  Statistics 
Report  for  the  entire  network  (Figure  3.30)  and  for  the  SPCC 
and  ASO  Systems  (Figures  3.31-3.32)  map  the  weekly  traffic 
statistics  found  on  the  LDCN  Status  Summary  onto  a  daily 
basis.  In  addition,  the  peak-hour  traffic  breakdown  is  given 
for  each  day.  The  Traffic  Statistics  Report  by  System  and 
Traffic  Type  (Figure  3.33)  allows  the  traffic  data  to  be 
filtered  by  System,  Concentrator,  and  Traffic  Type  before 
being  reported,  while  Traffic  Statistic  Plots  (Figure  3.34) 
show  the  number  of  messages  received  over  15-minute  intervals 
for  a  given  day.  As  in  the  User  Statistic  Reports,  the 
Traffic  Reports  probably  would  be  requested  only  during  system 
cutover,  while  Traffic  Statistic  Plots  for  the  entire  LDCN 
would  be  produced  after  each  system  cutover  or  every  six 
months . 

3.4.3  Response  Time 

Three  reports  would  deal  with  response  times.  The  LDCN 
Response  Time  Report  (Figure  3.35)  maps  the  average  response 
time  and  traffic  load  found  on  the  LDCN  Status  Summary  onto 
a  daily  basis.  The  peak-hour  response  time  and  traffic  load 
is  also  given  for  each  day.  The  Response  Time  Report  by 
System  (Figure  3.36)  filters  the  data  by  System  and  Concen¬ 
trator  before  reporting,  while  the  Response  Time  Report  by 
Component  (Figure  3.37)  shows  the  processing  and  queuing 
times  for  a  specific  concentrator  or  front  end.  These  reports 
would  be  requested  only  when  a  question  on  response  times 
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arose.  When  this  occurred,  the  Report  by  System  could  be 
run  to  isolate  the  problem  to  a  set  of  specific  concentrators 
and/or  systems.  The  Report  by  Component  would  then  be  run 
for  the  selected  items,  which  would  hopefully  answer  the 
question.  Given  this  scenario,  all  three  reports  should 
eventually  be  implemented. 


3.4.4  Message  Lengths 


Four  reports  would  deal  with  message  length  statistics. 
The  Message  Length  Statistic  Report  (Figure  3.38)  maps  the 
data  found  on  the  LDCN  Status  Summary  onto  the  ASO  and  SPCC 
Systems,  while  the  Report  by  System  and  Traffic  Type  (Figure 
3.39)  filters  the  message  length  data  before  processing  the 
report.  Message  length  histograms  for  input  and  output 
(Figures  3.40-3.41)  are  also  suggested  for  implementation. 
While  the  Statistical  Reports  would  only  be  used  for  debugging 
purposes,  the  histograms  would  be  run  after  system  implemen¬ 
tation  and  when  the  mean  or  standard  deviation  of  a  message 
type  varied  significantly  from  normal.  Because  of  this, 
the  histograms  should  be  implemented  before  the  other 
message  length  reports. 


3.4.5  CPU  Utilization 


CPU  Utilization  Engineering  Reports  would  consist  of 
four  documents.  The  CPU  Utilization  Report  (Figure  25.42) 
lists  on  a  daily  basis  the  data  found  in  the  LDCN  CPU  Uti¬ 
lization  Summary;  in  addition,  daily  peak-hour  utilization 
is  given.  The  CPU  Utilization  Report  by  Module  (Figure  3.43) 
further  refines  the  statistics  of  Figure  3.42,  while  the 
CPU  Module  Access  Report  (Figure  3.44)  looks  at  module 
accesses  rather  than  module  utilization.  Finally,  CPU  Utili¬ 
zation  Plots  (Figure  3.45)  shows  the  average  utilization 
of  a  CPU  over  15-minute  intervals  for  a  given  day.  All  four 
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reports  could  be  used  to  provide  detailed  information  on 
questions  raised  by  the  CPU  Utilization  Summary  or  Exception 
Reports;  however,  the  CPU  Utilization  Plots  would  probably 
be  the  most  used.  Because  of  this,  we  recommend  the  plots 
be  implemented  before  the  other  CPU  Utilization  Reports. 

3.4.6  Exception  Refinements 

Similar  to  the  CPU  Engineering  Reports,  eight  reports 
would  provide  detailed  information  on  questions  raised  by  the 
Buffer  Usage,  Output.  Queue,  Line  Notification,  Line  Utili¬ 
zation,  and  Disk  Utilization  Exception  Reports.  Figures 
3.46-3.53  show  the  format  of  these  reports.  Finally,  the 
Batch  Queue  Report  (Figure  3.54)  would  be  used  to  show  the 
ratio  of  time  criteria  batches  to  size  criteria  batches. 

This  report  would  mostly  be  used  for  system  modeling  purposes. 

3 . 5  Implementation  Schedule 

The  above  reports  are  a  subset  of  the  universe  of  possible 
reports  for  the  LDCN ;  however,  NAC  feels  they  cover  all  the 
key  statistics  in  the  LDCN's  universe.  The  question  of  which 
of  these  reports  should  be  implemented  may  now  be  asked. 

There  is  some  rationale  in  implementing  all  the  reports; 
however,  NAC  feels  that  this  would  require  FMSO  to  dedicate 
extraordinary  resources  to  the  statistical  package. 

Assuming  a  more  realizable,  limited  commitment  by  FMSO 
personnel  to  the  problem,  NAC  developed  Table  3.1.  This 
table  ranks  the  reports  in  terms  of  most  important  to  least 
important.  Rather  than  order  the  reports  in  terms  of 
importance,  seven  levels  of  importance  are  given.  This 
latter  approach  is  easier  and  somewhat  more  fair  than  a 
total  ordering  of  reports,  since  the  importance  of  a  report 
depends  on  a  number  of  factors  which  cannot  be  defined 
precise ly . 
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After  defining  the  various  report  levels,  NAC  then 
attempted  to  correlate  these  levels  to  the  latest  possible 
times  the  reports  could  be  implemented  without  having  a 
major  impact  on  the  network  by  not  providing  "necessary"  data. 
Thus  management  reports  and  operational  real-time  reports 
should  be  implemented  by  system  cutover.  These  reports  would 
allow  the  network  to  be  tracked  from  cutover,  and  could  be 
used  to  calibrate  network  models.  Within  the  next  6-9  months, 
the  other  operational  exception  reports  should  be  implemented. 
These  reports  require  "exceptional"  conditions  to  occur  to 
be  produced;  thus  to  test  them,  the  exceptional  performance 
limit  of  each  item  must  be  set  lower  than  the  normal  perfor¬ 
mance  seen  from  the  item.  After  the  reports  are  checked, 
the  limits  would  be  set  to  their  proper  values.  Two  additional 
exception  type  reports  should  be  available  by  the  end  of  the 
first  year.  By  the  end  of  the  second  year,  NAC  would  expect 
the  LDCN  to  have  implemented  key  engineering  reports,  although 
we  feel  the  traffic  statistic  plot  and  the  message  length 
histograms  should  be  implemented  before  this  period  if 
possible.  Finally,  the  other  engineering  reports  basically 
filter  the  data  found  above.  Because  of  this,  these  reports 
should  be  added  to  the  statistical  package  only  if  they  are 
requested  by  LDCN  network  control  center  personnel,  and/or  if 
they  can  be  implemented  easily  along  with  one  of  the  above 
"necessary"  reports. 

Whether  or  not  the  above  schedule  is  followed,  a  similar 
approach  to  the  problem  is  recommended  for  the  LDCN  statistical 
package  design  team. 
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Figure  3.8 

SUMMARY  OF  THE  DATA  PROPOSED  FOR  COLLECTION  BY  THE  LDCN 


I.  Data  for  System  Configuration  Statistics 

A.  Terminal  Logon,  Logoff,  and  System  Change 

1.  Terminal  Identification 

2.  Password 

3.  Terminal  Type 

a)  CRT,  TTY,  or  RJE 

b)  Linespeed 

c)  Character  Code 

d)  Synchronous  or  Asynchronous 

e)  Buffered  or  Non-Buffered 

f)  Dial-In  or  Leased  Line 

4.  System  Accessed 

5.  Concentrator  Accessed 

6.  Time  and  Date  of  Action  (Logon,  Logoff,  or  Change) 

B.  FEP,  Concentrator,  and  Host  Start-Up,  Shut-Down,  Failure,  Restoral 

1,  Equipment  Identification 

2.  Time  and  Date  of  Action 

C.  FEP  -  Concentrator  Line  Status  (Up,  Down) 

1.  Line  Identification 

2.  Time  and  Date  of  Action 

3.  Operator-Initiated  or  Automatic 

D.  FEP  -  Concentrator  Dial-Backup  Status  (Start  Use,  End  Use)  ^ 

1.  FEP  and  Concentrator  Identification 

2.  Time  and  Date  of  Action 

3.  Operator-Initiated  or  Automatic 

II.  Data  for  Traffic  Statistics 

A.  Date  and  Time  Message  Successfully  Enters  FEP 

B.  Traffic  Flow 

1.  Terminal  Identification 

2.  System 

3.  Count  of  Number  of  Entries  from  that  Terminal  to  that  System 
During  this  Session  -  Message  Number 


3.27 


Network  Analysis  Corporation 


C.  Traffic  Type  -  Message  Type 
1  „  Terminal-Terminal 

2.  Broadcast 

3.  Program  Type 

a)  Inquiry  or  Upquiry 

b)  Batch  or  Real-Time 

c)  AUTODIN  or  Non-AUTODIN 


[II.  Data  for  Message  Length  Statistics 

A.  Date  and  Time  Message  Successfully  Enters  FEP  on  Input  and  Output 

B.  Message  Type 

C.  Terminal  and  System  Identifiers 

D.  Input  and  Output  Message  Length 

E.  Message  Number 

IV.  Data  for  Response  Time  Statistics 

A.  FEP  and  Concentrator  Timings  on  Input  and  Output 

1.  Buffer  Allocated  for  Segment 

2.  Segment  Successfully  Received 

3.  Segment  Placed  on  Output  Queue 
A.  Buffer  for  Segment  Released 

B.  Output  Status  Flag 

1.  Output  Blocked  by  Another  Transmission 

2.  Output  Stored  Until  Next  Session 

C.  Traffic  Load 


Data  for  System  Utilization  Statistics 

A.  CPU  Utilizations  for  FEPs  and  Concentrators 

1.  Overall  Utilization  by  CPU 

2.  On  a  Module-by-Module  Basis  per  CPU 

B.  Disk  Utilization  for  FEPs  (and  Concentrators) 

1 .  Seek  Time 

2.  Processing 
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C.  Buffer  Utilization  for  FEPa  and  Concentrators 

1.  Buffer  Allocation  and  Restoration  Tines 

D.  Line  Utilization  for  FEP  -  Concentrator  Lines  and  FEP-Host  Channels 

1.  Line  or  Channel  Identification 

2.  Number  of  Characters  Transmitted  and  Direction  of  Transmission 

3.  Number  of  Retransmissions  on  Line 

4.  Linespeed  and  Character  Code 

E.  Core  Utilization  for  FEPs  and  Concentrators 

1 .  Programs 

a)  0/S 

b)  Applications 

2.  Buffering 

VI.  Data  for  Queuing  Statistics 

A.  FEP  Output  Queues  to  Hosts  and  Concentrators,  Concentrator  Output 
Queues  to  FEPs 

1.  Equipment  Identification  and  Queue  Number 

2.  Time  Segment  Placed  on  Output  Queue 

3.  Current  Number  of  Entries  on  Queue 

4.  Total  Number  of  Entries  on  Queue 

5.  Time  Buffer  is  Released 

B.  FEP  Batch  Queues 

1.  FEP  Identification  and  Queue  Number 

2.  Number  of  Items  in  Batch 

3 .  Criteria  Flag 

a)  Batch  Limit  Met 

b)  Time  Limit  Met 

VII.  Data  for  Error  Statistics 

A.  Terminal-Concentrator  Line  Errors 

1.  Line  Identification 

2 .  Error  Type 

a)  Message  in  Error  -  Retransmit 

b)  User  Requests  Message  Retransmission 


Network  Analysis  Corporation 


B. 


C. 


D. 


E. 


FEP  -  Concentrator  Line  Error 

1.  Line  Identification 

2.  Error  Type 

a)  Message  in  Error  -  Retransmit 

b)  Time-Out  Occurred 

c)  Terminal  Requests  Message  Retransmission 

d)  Concentrator  Requests  All  Messages  be  Retransmitted 
FEP-Host  Channel  Errors 

1.  Channel  Identification 

2 .  Error  Type 

a)  Message  in  Error  -  Retransmit 

b)  Time-Out  Occurred 
Congestion  Reports 

1.  Concentrator:  FEP-Concentrator  Messages 

a)  Concentrator  Congested  -  'Wait 

b)  Continue  Transmission 

2.  FEP:  FEP-Host  Messages 

a)  FEP  Congested  -  Retransmit  After  Pause 

b)  FEP  Workload  Excessive  -  Wait 

c)  Continue  Transmission 

3.  Queues 

a)  NX  Utilized 

b)  Queue  Overflow 
Other  Errors  Detected  by  FEP 

1.  Transmission  from  Host  Queue  N  Lost  -  Please  Retransmit 

2.  Three  Incorrect  Passwords  Detected 
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LDCN  STATUS  SUMMARY  (continued) 
FOR  WEEK  FROM  nnn/dd/yy  TO  mm/dd/yy 
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Figure 
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STARTED- UP 

|  CONCENTRATOR:  xxxx  SHUT-DOWN 

mm/dd/yy  hhrtnm  J  FEp.  xxxx  >  FAILED 

[^LINE:  xxxx  J  RESTORED 

a)  System  Status  Update  Report 


mm/dd/yy  hh:mm  USER  ID:  xxxx  INVALID  PASSWORD 

d)  Invalid  Password  Update  Report 


Figure  3.14  -  REAL-TIME  REPORTS 
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Figure  3.15 
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Figure  3.18 


Figure  3.19 


(list  in  descending  order  by  number  of  entries  per  user  id) 
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Figure  3.20 
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Figure  3.21 


DISK  UTILIZATION  EXCEPTION  REPORT 
FOR  WEEK  FROM  mm/dd/yy  TO  mm/dd/yy 
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Figure  3.23 
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Figure  3.26 
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TIME  OF  DAY 
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Figure  3.29 
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LDCN  TRAFFIC  STATISTICS  REPORT 
FOR  WEEK  FROM  mm/dd/yy  TO  mm/dd/yy 
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LDCN  TRAFFIC  STATISTICS  REPORT  (continued) 
FOR  WEEK  FROM  mm/dd/yy  TO  om/dd/yy 
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LDCN  TRAFFIC  STATISTICS  REPORT  (continued) 
FOR  WEEK  FROM  nm/dd/yy  TO  mm/dd/yy 
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TRAFFIC  STATISTICS  REPORT  BY  SYSTEM  AND  TRAFFIC  TYPE 
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AVERAGE  RESPONSE  TIME  (SEC.) 


RESPONSE  TIME  REPORT  BY  SYSTEM 
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Figure  3.36 
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MESSAGE  LENGTH  STATISTICS  REPORT  BY  SYSTEM  AND  TRAFFIC  TYPE  (continued) 
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Figure  3.46 
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LINE  UTILIZATION  REPORT 
FOR  WEEK  FROM  mm/dd/yy  TO  mm/dd/yy 


Figure  3.5 


UTILIZATION  PLOT  FOR  mm/dd/yy 


Network  Analyeia  Corporation 


B 


U£ 

m 


t - ^ - N 


as 

o 

M 


f-i 

3 


<"i 

m 


n 


01 

». 

3 

CO 


3.83 


Figure  3.54 
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4.  MEASUREMENT  MECHANISMS 


4 . 1  Approach 

In  the  previous  section,  the  proposed  statistical  reports 
for  the  LDCN  were  discussed.  In  this  section,  a  way  of 
collecting  the  data  for  these  reports  is  proposed.  This 
collection  process  is  designed  on  the  assumption  that  the 
collection  mechanisms  will  be  an  integral  part  of  the  operating 
system  and  will  have  minimal  impact  on  the  processors.  Thus 
it  is  envisioned  that  none  of  the  collection  processes  would 
be  under  operator  control  for  start-up  or  shut-down,  except 
for  the  system  snapshot  record,  which  would  require  operator 
initiation  of  the  snapshot. 

The  proposed  collection  mechanisms  are  based  on  a  "history 
tape"  recording  system;  that  is,  each  front  end  would  journal 
statistical  data  on  a  magnetic  tape  as  the  data  became 
available.  Each  tape's  label  would  identify  the  front  end 
that  produced  it.  For  efficient  tape  utilization,  blpcks 
of  50-100  statistical  records  would  be  written  to  tape.  Each 
block  would  have  a  header  containing  the  date  and  time  of  the 
first  and  last  records  on  the  block,  and  a  cell  indicating 
one  of  six  block  types.  These  block  types  are  described  in 
Section  4.2. 

The  above  tape  format  would  permit  efficient  off-line 
processing  of  statistical  data,  since  blocks  of  records 
which  have  the  wrong  type  data  or  wrong  time  period  could  be 
quickly  ignored.  To  form  these  blocks,  records  would  be 
grouped  on  disk  before  being  written  to  tape.  Thus  six 
different  groups  would  be  collected  on  disk  at  any  given 
time.  If  disk  space  prohibitted  the  use  of  six  groups, 
fewer  groups  could  be  implemented;  however,  off-line  pro¬ 
cessing  could  increase  due  to  an  increase  in  scanning  indi¬ 
vidual  unwanted  records.  Similarly,  the  number  of  records 
per  block  should  be  chosen  to  minimize  the  processing  of 
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unwanted  records.  For  example,  a  1000  record  block  might 
contain  records  spanning  two  hours.  If  only  the  second  hour's 
data  is  needed,  then  500  unwanted  records  could  be  processed 
to  get  to  the  needed  data.  However,  blocks  of  100  records 
would  span  12  minutes;  thus  only  five  block  headers  would  be 
processed  before  ariving  at  the  needed  data.  As  the  network 
becomes  more  heavily  utilized,  longer  blocks  could  be 
created;  however,  disk  space  constraints  would  prohibit 
infinite  expansion,  lo:  these  reasons,  we  suggest  an  initial 
blocksize  of  50-100  records. 

As  a  minimum,  each  front  end  should  have  enough  history 
tapes  to  be  on  a  30-day  "reuse"  cycle.  Sixty  to  90  day  cycles 
are  more  typical  for  "history  tape"  systems;  thus  we  recom¬ 
mend  consideration  of  these  cycle  lengths  for  the  LDCN .  During 
a  cycle,  a  front  end  would  collect  data  on  a  history  tape. 

Since  it  would  be  easier  for  the  network  control  center  (NCC) 
to  process  tapes  on  a  daily  basis  rather  than  on  a  weekly 
basis,  a  front  end  would  daily  send  its  completed  history 
tape  to  the  NCC;  in  addition,  the  statistical  reports  to  be 
produced  for  the  week  would  have  to  be  known  in  advance  of  the 
week.  All  history  tapes  would  nominally  be  held  by  the  NCC 
for  at  most  two  weeks;  one  week  for  the  processing  of  weekly 
summary  reports,  and  one  week  for  the  processing  of  engineering 
reports  requested  on  the  basis  of  the  summary  reports.  At 
the  end  of  this  period,  the  tape  would  be  returned  to  the 
front  end  for  reuse.  This  scenario  describes  an  instantaneous 
interaction  between  front  ends  and  the  NCC,  and  between  sum¬ 
mary  reports  and  requests  for  detailed  data.  In  actuality,  a 
day  to  a  week  could  transpire  between  these  items.  For  these 
reasons,  we  feel  a  30-day  cycle  is  a  minimum  requirement. 

Finally,  since  each  concentrator  will  be  dual-homed  to 
two  front  ends,  each  would  output  its  statistics  to  its 
primary  front  end  unless  otherwise  notified. 
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4 . 2  Statistical  Blocks 

The  data  proposed  for  collection  by  the  LDCN  would  be 
formatted  into  one  of  26  records  for  the  history  tape. 

Each  record  would  contain  a  record  identity  number,  the  size 
of  the  record  in  bytes ,  and  the  date  and  time  the  data  was 
received  by  the  front  end.  The  front  end  would  be  responsible 
for  identifying  the  concentrator,  host,  or  component  repre¬ 
sented  by  the  data,  if  this  information  was  not  part  of  the 
data.  Finally,  as  each  record  was  written  to  disk,  it  could 
also  be  printed  at  a  console.  Thus,  a  hook  for  on-line  statistics 
would  be  available,  although  we  are  not  recommending  its  use 
at  this  time. 

The  proposed  records  for  the  LDCN  can  be  placed  into  six 
statistical  block  types.  These  types  are  Configuration 
Statistics,  Traffic  and  Message  Statistics,  Response  Time 
Statistics,  System  Utilization  Statistics,  Queuing  Statistics, 
and  Error  Statistics.  Let  us  now  look  at  these  block  types 
in  more  detail. 

4.2.1  Configuration  Statistics 


The  five  record  types  composing  the  Configuration 
Statistical  Block  are  shown  in  Figure  4.1.  Logon,  system 
change,  and  logoff  records  would  be  created  when  the  concen¬ 
trator-supplied  data  was  entered  in  the  FEP's  Configuration 
Table.  Status  change  records  would  be  recorded  when  an  on-line 
status  change  report  was  printed  at  the  FEP's  console.  These 
four  records  would  be  sufficient  for  all  configuration  pro¬ 
cessing  needs;  however,  the  System  Configuration  Report  could 
be  more  easily  produced  if  at  "snapshot  time,"  each  active 
entry  in  the  FEP's  Configuration  Table  was  captured  in  a 
System  Snapshot  record.  This  record  is,  therefore,  proposed 
as  the  fifth  configuration  data  record;  in  addition,  it  is  the 
only  one  of  the  proposed  records  that  would  be  collected  by 
operator  initiation. 
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4.2.2  Traffic  and  Message  Statistics 

The  two  record  types  composing  the  Traffic  and  Message- 
Statistical  Block  are  shown  in  Figure  4.2.  These  records 
would  be  produced  by  the  FEP  after  it  had  successfully  received 
an  entire  input  or  output  message.  The  message  lengths  could 
be  calculated  as  follows.  As  the  first  segment  of  an  input 
message  was  processed  by  a  FEP,  an  entry  would  be  made  in  an 
I/O  Table.  Each  entry  in  the  table  would  contain  space  for 
Concentrator  and  Terminal  ID,  Message  Number,  Message  Type, 
Program  Type,  and  Message  Size.  The  first  input  segment  would 
supply  the  initial  data  for  all  six  fields.  Each  additional 
input  message  segment  would  add  its  segment  size  to  the 
message  size  field  in  the  corresponding  message  entry.  After 
the  last  input  segment  had  added  its  segment  size  to  the  cor¬ 
responding  Message  Size  field,  the  Input  Message  Record  would 
be  created  and  the  entry  in  the  I/O  Table  would  be  deleted. 

A  similar  procedure  would  be  used  to  create  the  Output  Message 
Record . 

4.2.3  Response-Time  Statistics 

The  Response-Time  Statistics  Block  is  composed  of  eight 
record  types  (Figure  4.3).  Concentrator- Input  Records  and 
Concentrator-Output  Records  should  be  received  from  concen¬ 
trators  once  every  15  minutes  to  one  hour,  with  NAC  recom¬ 
mending  the  former  value.  These  records  could  be  created  as 
follows.  Each  concentrator  would  have  four  32-bit  words  set 
aside  for  input,  and  four  set  aside  for  output.  Word  one 
would  be  a  processing  time  cell;  the  second  would  be  a  queuing 
time  cell,  while  the  third  would  be  a  buffer  utilization  cell. 
The  fourth  cell  would  contain  a  count  of  the  number  of  entries 
in  the  other  cells.  When  a  buffer  was  allocated  for  an  input 
segment,  the  concentrator  would  subtract  the  rightmost  16  bits 
of  a  one  millisecond  interval  timer  from  the  third  input  cell. 
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When  the  input  segment  was  successfully  within  the  concen¬ 
trator,  the  rightmost  16  bits  of  the  timer  would  be  subtracted 
from  the  first  cell.  When  the  segment  was  placed  on  the  con¬ 
centrator's  output  queue,  the  rightmost  16  bits  of  the  timer 
would  be  added  to  cell  one  and  subtracted  from  cell  two. 

Finally,  when  the  buffer  for  the  segment  was  released,  the 
rightmost  16  bits  of  the  timer  would  be  added  to  cells  two 
and  three,  and  cell  four  would  be  tallied  by  one.  (It  should 
be  noted  that  although  "halfword"  arithmetic  is  being  carried 
out  in  the  cells,  the  entire  32  bits  would  contain  timing 
data,  with  the  high  order  bits  being  a  result  of  carries  out 
of  the  low  order  bits.)  A  similar  operation  would  be  per¬ 
formed  for  the  output  message  segments.  Finally,  once  every 
15  minutes  to  one  hour  (a  system-defined  parameter) ,  the  con¬ 
centrator  would  send  the  four  input  cells  and  four  output 
cells  to  its  primary  FEP  and  would  then  zero  out  the  cells. 

Upon  receiving  this  information,  the  FEP  would  append  the 
proper  record  header  and  place  the  record  on  disk  for  future 
processing  by  the  statistics  program. 

The  FEP  Input- In  Record  would  be  created  by  the  FEP 
when  the  last  segment  of  an  input  message  was  successfully 
received.  The  Input-Out  Record  would  be  created  when  the 
first  segment  of  a  real-time  input  message  was  placed  on  one 
of  the  FEP's  output  queues.  When  the  output  buffer  for  the 
last  segment  of  a  real-time  input  message  was  released,  the 
Input-Done  Record  would  be  generated.  On  the  message  output 
side,  the  Output-In  Record  would  be  generated  when  the  first 
segment  of  an  output  was  successfully  received  by  the  FEP,  while 
the  Output-Out  Record  would  be  created  when  that  first  segment 
was  placed  on  an  output  queue  for  a  concentrator.  The  Output 
Status  Flag  of  the  Output-Out  Record  would  indicate  whether 
the  message  was  blocked  by  another  transmission  or  by  the 
terminal  logging  off  the  system.  Finally,  the  Output-Done 
Record  would  be  created  when  the  output  buffer  for  the  first 
segment  was  released. 
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4.2.4  System  Utilization  Statistics 

The  System  Utilization  Statistical  Block  contains  four 
types  of  records.  The  CPU  and  Disk  Records  would  be  collected 
for  both  FEP's  and  concentrators,  while  the  Buffer  Records 
would  only  be  collected  for  the  FEP's.  (Concentrator  buffer 
utilization  would  be  obtained  from  the  Response  Time  Statis¬ 
tical  Records.)  Raw  utilization  data  would  be  obtained  in 
the  concentrator  and  FEP  software  programs  which  could  period¬ 
ically  sample  device  utilization  and  forward  this  information 
to  the  appropriate  FEP.  In  addition,  a  32-bit  word  would  be 
kept  by  the  operating  system  for  each  program  module  and  disk. 
Whenever  an  access  was  made  to  a  module  or  disk,  the  appro¬ 
priate  word  would  be  tallied.  This  data  would  be  sent  along 
with  the  utilization  to  the  FEP;  when  this  was  done,  the  cells 
would  be  reinitialized  to  zero.  At  the  FEP,  the  raw  data 
would  be  formatted  into  the  appropriate  records.  Figure  4.4 
shows  the  four  utilization  records. 

4.2.5  3ueue  Statistics 

There  are  two  types  of  Queue  Statistical  Records  (Figure 
4.5).  The  Queue  Record  would  use  data  from  software  programs 
that  could  sample  the  queue  every  N  milliseconds  to  determine 
the  average  queue  length.  In  addition,  each  queue  could  have 
three  calls  associated  with  it.  The  first  cell  would  contain 
the  total  number  of  entries  on  the  queue;  it  would  be  tallied 
each  time  an  item  joined  the  queue.  The  second  cell  would 
contain  the  maximum  queue  length  observed  while  the  third 
Cell  would  have  the  current  queue  length.  When  an  item 
joined  the  queue,  the  third  cell  would  be  tallied  and  com¬ 
pared  against  the  second  cell;  if  the  third  cell  was  larger, 
then  the  second  cell  would  receive  the  third  cell's  value. 

Cell  one  would  then  be  tallied.  When  an  item  left  the  queue, 
the  third  cell  would  be  decremented  by  one.  The  first  and 
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second  cells  would  be  reported  along  with  the  average  queue 
length  in  the  Queue  Record;  after  this  data  was  sent  to  the 
appropriate  FEP ,  the  first  cell  would  be  set  to  zero  and  the 
second  would  be  set  to  the  current  queue  length. 

The  E'.atch  Report  is  the  second  type  of  Queue  Statistical 
Record.  This  record  would  contain  the  number  of  transactions 
on  the  batch  queue,  in  addition  to  whether  the  queue  was 
outputted  because  of  time  or  size  criteria.  This  record  would 
be  created  by  the  FEP  when  it  placed  the  batch  on  an  output 
queue . 

4.2.6  Error  Statistics 


Five  types  of  reports  are  contained  in  the  Error  Statistics 
Block.  Line  Error  Records  (Figure  4.6)  would  be  written  by 
the  FEP  whenever  a  retransmission  was  requested  over  a  line. 

The  FEP  could  automatically  create  these  records  when  it 
received  or  gave  a  retransmission  request;  thus  only  concen¬ 
trator-terminal  lines  would  have  to  be  handled  by  the  concen¬ 
trator.  When  it  received  or  gave  a  request  to  a  terminal, 
the  concentrator  would  forward  the  information  to  the  appro¬ 
priate  FEP  for  journalling.  In  addition,  at  the  FEP,  the 
number  of  "time-out"  and  "error  in  message"  errors  could  be 
tallied  in  two  colls  associated  with  an  "active  I/O  line" 
table.  If  either  cell  was  greater  than  its  permissible  limit, 
or  if  the  addition  of  the  cells  was  greater  than  their  allowed 
combined  limit,  an  Excessive  Line  Error  Report  would  be 
issued  on-line  and  journalled  on  the  history  tape.  Whenever 
a  line  or  buffer  overflow  occurred,  the  information  would  be 
sent  to  the  FEP  for  on-line  reporting  and  capture  in  the  Over¬ 
flow  Error  Record.  Similarly,  password  failure  data  would  be 
reported  on-line  and  recorded  in  a  Password  Failure  Record. 
Finally,  Congestion  Error  Records  would  be  produced  whenever 
"congestion  requests"  were  issued  or  received  by  the  FEP. 
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4 . 3  Summary 

This  section  presented  an  overview  of  the  data  needed 
for  the  proposed  statistical  reports  of  Section  3.  A  possible 
mechanism  to  collect  this  data  was  also  presented.  In  the 
next  section,  some  algorithms  to  convert  this  raw  data  into 
the  reports  are  given. 
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5.  PROCESSING  METHODOLOGY 

In  Section  3,  44  management,  operational,  and  engineering 
reports  were  proposed,  while  26  statistical  records  were 
proposed  in  the  preceeding  section.  In  order  to  convert  the 
above  input  records  into  output  reports,  a  processing  method¬ 
ology  must  be  defined.  The  methodology  can  be  as  simple  as 
list  all  type  X  input  records,  or  as  complicated  as  multiply 
field  A  of  card  B  by  field  C  of  card  D  and  use  result  as  a 
pointer  into  a  data  base  for  the  value  to  be  printed.  The 
more  complicated  the  methodology,  the  more  costly  is  the 
statistics  subsystem. 

This  section  discusses  a  proposed  methodology  for  the 
LDCN  statistical  package.  Section  5.1  discusses  those  output 
reports  that  would  be  little  more  than  line-by-line  listings 
of  various  input  records,  while  Section  5.2  discusses  those 
reports  with  intermediate  processing  requirements.  The  use 
of  a  data  base  in  producing  reports  is  discussed  in  Section 
5.3.  Finally,  Section  5.4  reviews  the  complex  processing 
requirements  proposed  for  the  LDCN  reports,  while  Section  5.5 
gives  an  overview  of  a  set  of  programs  that  could  be  used 
to  process  the  statistical  reports. 

5 . 1  Simple  Processing  Methodologies 

Of  the  44  proposed  LDCN  outputs,  15  are  little  more  than 
line-by-line  transfers  from  an  input  record  to  an  output 
line.  Table  5.1  shows  these  output  reports  and  the  corre¬ 
sponding  input  records.  The  System  Status  Report  and  the 
System  Configuration  report  are  line-by-line  transfers  as 
are  the  CPU  Utilization,  Buffer  Usage,  Output  Queue,  and 
Disk  Utilization  Plots.  To  obtain  the  message  length  histo¬ 
grams,  the  number  messages  of  length  N  would  be  counted  and 
divided  by  the  total  number  of  messages  to  obtain  a  point  on 
the  graph  equal  to  (character  size  N,  percent  of  messages) . 
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The  Traffic  Statistics  Plot  would  be  obtained  by  counting  the 
nvunber  of  messages  over  each  time  interval,  while  the  User  Status 
Plot  could  be  obtained  by  listing  the  cumulative  number  of 
daily  logons  at  each  time  period  of  interest  on  the  graph 
and  subtracting  the  cumulative  number  of  logoffs  from  this 
value.  The  Password  Failure  Report,  Line  Notification  Report, 
and  Congestion  Report  would  require  the  input  records  to  be 
sorted  according  to  component  identifier  before  being  tallied. 

The  Average  Congestion  Interval  on  the  Congestion  Report 
would  be  obtained  by  summing  the  times  on  all  the  "continue" 
records,  subtracting  from  this  the  time  on  all  the  "wait" 
records,  and  dividing  by  the  number  of  "wait"  records.  The 
LDCN  CPU  Utilization  Summary  would  require  using  only  those 
utilization  records  collected  during  the  prime  time.  These 
records  would  then  be  sorted  according  to  CPU;  the  utilizations 
for  a  given  CPU  are  then  summed  and  divided  by  the  number  of 
records  for  that  CPU.  Finally,  the  System  Signon-Signof f 
Report  would  require  the  matching  of  Logon  and  Logoff  Records 
before  an  output  line  was  produced. 

5 . 2  Intermediate  Processing  Methodologies 

The  11  reports  listed  in  Table  5.2  would  require  inter¬ 
mediate  processing  methodologies  to  be  produced.  Of  the  11 
reports  listed,  the  CPU  Utilization,  Buffer  Usage,  Output 
Queue,  and  Disk  Utilization  Reports  are  all  very  similar  in 
nature.  Thus  by  mentioning  a  processing  strategy  for  the  CPU 
Utilization  Report,  the  processing  for  the  other  reports  should 
become  obvious.  The  CPU  Utilization  Report  is  a  more  detailed 
version  of  the  LDCN  CPU  Utilization  Summary  discussed  above. 
Whereas  the  Summary  would  list  a  weekly,  prime-time,  average 
utilization,  the  CPU  Utilization  Report  would  list  prime¬ 
time,  average  utilization  on  a  daily  basis.  In  addition, 

CPU  Utilization  would  be  calculated  on  an  hour-by-hour  basis 
to  determine  the  peak  utilization  per  hour  and  its  peak  hour. 
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The  CPU  Utilization  Report  by  Module  and  CPU  Module 
Access  Report  would  require  more  processing  and  sorting  to 
be  produced.  These  reports  are  more  detailed  copies  of  the 
CPU  Utilization  Report.  It  should  also  be  noted  that  the 
peak  hour  utilization  on  these  reports  would  refer  to  the 
total,  not  to  each  individual  component. 

The  values  listed  in  the  three  response  time  reports 
would  be  approximate.  An  example  of  response  time  calcu¬ 
lations  for  a  given  hour  would  be: 

a.  Sum  together  the  processing  time  fields  for  all 
Concentrator  Input  Records.  Also  apply  this  addition 
to  the  queuing  time  fields,  the  buffer  utilization 
fields,  and  the  number  of  entries  field. 

b.  Follow  a  similar  procedure  for  the  Concentrator 
Output  Records. 

c.  Divide  the  number  of  entries  field  into  the  other 
three  fields  for  both  record  types. 

d.  Sort  FEP  Records  10-15  into  sets  based  on  Concen¬ 
trator,  Terminal  ID,  and  Message  Number. 

e.  Discard  incomplete  sets,  as  well  as  sets  whose 
Output  Status  Flag  in  Record  14  is  set  to  "S". 

f.  Calculate  the  time  difference  in  seconds  between 
Records  10  and  15  and  average  over  all  remaining 
sets . 

g.  The  average  response  time  for  the  hour  is  approximately 
the  processing  and  queuing  times  from  the  Concen¬ 
trator  Input  Records  plus  the  value  in  (f)  plus  the 
processing  time  value  from  the  Concentrator  Output 
Records . 
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Other  response  time  values  and  components  would  be  possible 
from  these  values,  however,  the  above  steps  show  how  such  cal¬ 
culations  could  be  carried  out. 

Finally,  the  User  Status  Reports  would  have  to  worry 
about  logons  occurring  before  prime-time  and  lasting  into 
prime  time,  as  this  would  affect  the  validity  of  the  reports. 
There  would  be  no  easy  way  to  remedy  this  problem  except  by 
processing  logon-logoff  records  with  time  values  starting 
about  two  hours  before  prime-time. 

5.3  Need  for  a  Data  Base 


Thirteen  proposed  LDCN  reports  would  require  outside 
data  to  be  produced.  These  13  are  listed  in  Table  5.3  along 
with  the  data  required.  In  processing  the  reports,  the  LDCN 
statistical  package  would  follow  the  methodologies  mentioned 
above . 

The  data  listed  in  Table  5.3  suggests  that  at  least  two 
data  bases  should  be  established  for  statistics.  The  first 
data  base  would  contain  the  data  needed  for  the  summary  plots, 
while  the  second  would  contain  component  performance  limits 
and  component  specifications.  With  these  data  bases  all  13 
reports  could  be  easily  produced. 

5 . 4  Complex  Processing  Methodologies 

The  five  remaining  LDCN  reports  shown  in  Table  5.4  fall 
into  the  Complex  Processing  Methodology  Class.  These  reports 
are  concerned  with  obtaining  the  mean,  standard  deviation, 
and  maximum  message  lengths.  The  following  algorithm  could 
be  used  to  determine  each  of  these  values  from  a  given  set 
of  data: 
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INITIALIZATION:  MAX 

XOLD 

SOLD 

N 

INPUT:  READ 

IF  LENGTH  >  MAX  THEN  MAX 

X 

XNEW 

SNEW 


=  0; 

=  0; 

=  0; 

=  0; 

LENGTH ; 

=  LENGTH;  /‘RUNNING  MAXIMUM*/ 

=  LENGTH; 

=  (XOLD*N+X)/(N+l) ; /‘RUNNING  MEAN*/ 
=  {N* (SOLD+XOLD*XOLD-2*XNEW*XOLD 
+XNEW*XNEW) + (X-XNEW) **2) / (N+l) ; 

/‘RUNNING  SD*/ 


N  =  N  +  1; 

XOLD  =  XNEW; 

SOLD  =  SNEW; 

IF  (MORE  DATA)  THEN  GO  TO  INPUT: 
ELSE  OUTPUT  XOLD,  SQRT  (SOLD),  MAX: 


Where  XOLD,  SQRT  (SOLD),  and  MAX  are  the  mean,  standard 
deviation,  and  maximum,  respectively. 

5 . 5  Statistical  Processing  Overview 

There  are  many  possible  processing  scenarios  for  con¬ 
verting  the  LDCN  statistical  input  records  into  output  reports. 
One  such  scenario  incorporates  the  use  of  seven  files  and  four 
distinct  program  types.  This  scenario  allows  for  the  processing 
of  history  tapes  on  a  day-by-day  basis,  and  notifies  the  pro¬ 
gram  operators  of  missing  data  before  printing  out  the  reports. 
This  scenario  is  described  below  in  terms  of  the  different 
files  and  program  types. 

5.5.1  Files 


The  seven  files  proposed  for  use  in  processing  the  LDCN 
statistical  data  are: 
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a.  The  Total  Traffic  per  Week  file  would  be  a  sequential 
file  which  would  contain  two-field  entries.  The  first 
field  entry  would  contain  the  start  date  of  the  week 
(MMDDYY) ,  while  the  second  entry  would  contain  the 
total  number  of  LDCN  messages  for  that  week.  An 
entry  would  be  placed  at  the  end  of  the  file  when 

the  weekly  LDCN  Status  Summary  was  created;  the  last 
104  entries  would  then  be  used  to  create  the  Traffic 
Summary  Plot.  Once  a  year  an  update  program  would 
be  run  to  discard  file  entries  more  than  two  years 
old  and  to  compress  the  file. 

b.  The  Average  Traffic  per  Hour  file  would  be  a 
sequential  file  similar  to  the  one  above. 

c.  The  Performance  file  would  be  an  indexed  file 
which  would  use  device  identification  numbers  and 
device  types  as  indices.  CPU  and  disk  entries 
would  also  have  fields  for  down-time  and  utilization 
limits.  Buffer  and  queue  entries  would  contain  the 
warning  limit  size  and  the  maximum  buffer  or  queue 
size,  while  batch  queue  entries  would  contain  infor¬ 
mation  on  time  and  size  criteria.  Line  and  channel 
entries  would  contain  down-time  and  utilization 
limits,  error  limits  for  messages,  time-outs,  and 
combinations  of  the  two,  and  line  characteristics 
(line  discipline,  capacity,  and  character  codes) . 

This  file  would  be  updated  when  changes  to  the  system 
were  made . 

d.  The  Traffic  Algorithm  file  would  be  an  indexed  file 
which  would  map  terminal  identification,  system 
accessed,  and  program  type  into  batch,  real-time, 
inquiry,  upquiry,  AUTODIN,  and  non-AUTODIN  traffic 
types.  Indexing  would  be  performed  on  the  first 
three  fields  of  this  nine  field  card. 
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e.  The  Output  Information  file  would  be  a  sequential 
file  sorted  by  output  report  number.  Each  entry  would 
contain  an  output  report  number,  the  input  records 
needed  to  produce  that  report,  and  the  filtering 
limits  permissible  for  that  report  (e.g.,  data  needed 
for  entire  week  or  just  one  day,  prime-time  hours 
allowed,  and  system,  concentrator,  and  traffic 
filters  allowed) . 

f.  The  Output  Request  file  would  be  a  sequential  file 
of  the  reports  requested  from  the  LDCN.  Each  entry 
in  this  file  would  contain  a  request  number,  an  out¬ 
put  report  number,  the  start  date  of  the  week  for 
which  the  report  is  requested,  the  filtering  limits 
to  be  used  in  preparing  the  report  (e.g.,  start  and 
end  values  for  the  prime  time) ,  and  two  seven  char¬ 
acter  fields.  One  field  would  indicate  the  day’s  data 
needed  to  be  collected  from  the  SPCC  system  in  order 
to  produce  the  report;  the  other  field  would  indicate 
this  for  the  ASO  system.  A  "1"  in  position  i  of 
either  field  would  indicate  data  needed  to  be 
collected  for  the  1  day  of  the  week;  a  "0"  would 
indicate  that  data  was  not  needed  for  that  day; 
while  a  "2"  would  indicate  data  was  already  collected 
for  that  day.  This  file  can  thus  be  used  to  give  the 
status  of  each  output  request. 

g.  The  Output  Data  file  would  be  used  to  store  output 
results  for  formatting  by  the  report  generator. 

This  indexed  file  would  contain  information  on  all 
reports;  each  entry  would  therefore  contain  request 
number,  output  report  number,  date,  information 
segment  number,  FEP  accessed,  and  the  output 
information.  Indexing  would  be  by  request  and 
report  number. 
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5.5.2  Processing  Organization 


The  above  seven  files  would  interact  as  follows.  At  the 
beginning  of  each  week,  the  LDCN  Network  Control  Center  (NCC) 
would  run  a  program  which  appended  requests  for  the  managerial 
and  operational  reports  onto  the  Output  Request  file.  In 
addition,  a  program  would  be  run  which  placed  the  engineering 
report  requests  for  the  week  on  the  file.  This  second  pro¬ 
gram  would  use  the  Output  Information  file  to  validate  the 
engineering  requests  inputted;  incorrect  requests  would  not 
be  placed  on  file  but  outputted  along  with  an  error  code. 

These  requests  could  then  be  corrected  and  re-entered  by  the 
second  program.  Both  programs  would  set  the  appropriate 
bytes  in  the  ASO  and  SPCC  fields  of  each  new  Output  Request 
entry  to  one.  Because  of  this,  these  programs  could  be  run 
anytime  during  the  processing  cycle. 

As  each  tape  from  the  ASO  or  SPCC  front  end  arrived 
daily  at  the  NCC,  it  would  be  processed  by  a  second  distinct 
program  type.  This  program  would  use  the  Output  Information 
file  and  Output  Request  file  to  determine  what  data  needed 
processing  and  outputting  on  the  Output  Data  file.  The  pro¬ 
gram  would  use  the  Traffic  Algorithm  file  to  determine  traffic 
and  message  type  information,  while  the  Performance  file  would 
be  used  to  determine  what  information  should  be  outputted  for 
the  exception  reports.  Each  tape  processed  by  the  program 
would  have  a  header  indicating  the  FEP  it  came  from,  so  the 
filtering  of  data  according  to  the  ASO  or  SPCC  system  would 
not  occur  on  an  individual  record  basis,  but  on  an  entire 
tape  basis.  If  data  were  to  be  filtered  according  to  sub¬ 
systems  (e.g.,  AICS  or  AWPS) ,  a  temporary  file  indexed  by 
subsystem  and  terminal  would  be  created  to  journal  the  logon- 
logoff  periods  of  each  terminal  on  each  subsystem.  Other 
input  records  would  then  be  filtered  against  this  file  in 
order  to  obtain  the  appropriate  output  report  segment. 
Similarly,  other  temporary  files  or  storage  will  be  needed 
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for  calculating  and  processing  the  various  output  report  seg¬ 
ments.  When  the  program  is  done  processing  the  tape,  it 
changes  the  appropriate  byte  of  the  ASO  or  SPCC  field  of 
each  appropriate  Output  Request  entry  from  a  one  to  a  two; 
it  then  formats  each  output  segment  and  places  it  on  the 
Output  Data  file. 

The  third  distinct  program  type  would  be  run  at  the  end 
of  the  week.  This  program  would  first  check  the  Output 
Request  file  to  see  if  some  data  was  processed  on  each  day 
required  by  each  output  request.  This  check  is  performed  by 
looking  for  a  value  of  one  in  the  ASO  and  SPCC  fields  of  each 
entry.  If  some  ones  were  found,  the  program  would  output  on 
the  console  and  on  the  printer  the  needed  tapes  by  system 
type  and  date.  It  would  then  ask  the  operator  "GO  OR  NOGO?". 
If  the  operator  responded  "NOGO,"  the  program  would  terminate 
so  the  operator  could  run  the  second  program  type  to  input  the 
needed  data.  If  the  operator  responded  "GO,"  the  output 
requests  with  missing  data  would  not  produce  reports  at  this 
time.  This  would  allow  the  missing  data  to  be  inputted 
during  the  next  week.  However,  to  guarantee  that  all  output 
requests  are  eventually  satisfied,  the  program  would  output 
all  reports  whose  collection  week  was  more  than  N  weeks  before 
the  current  processing  date.  For  the  LDCN,  an  N  equal  to  two 
is  appropriate.  Thus  with  this  value,  all  detailed  data  for 
engineering  reports  requested  as  a  result  of  the  summary 
report  data  must  be  present  at  reporting  time  or  the  reports 
will  be  produced  without  the  data.  For  each  request  to  be 
filled,  the  program  would  then  collect,  sort,  process,  and 
format  the  appropriate  output  segments  into  a  complete  report. 
Finally,  the  program  would  make  the  appropriate  entries  on 
the  Total  Traffic  per  Week  and  Average  Traffic  per  Hour  files, 
and  output  the  reports  associated  with  thise  files. 

The  last  program  type  would  be  run  after  the  above  pro¬ 
gram.  This  program  would  purge  the  filled  requests  from  the 
Output  Request  file  and  compress  the  file.  It  would  also 
purge  the  reported  data  from  the  Output  Data  file  and  com¬ 
press  it.  These  functions  are  performed  in  a  separate 
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program  run  after  the  above  report  generator  so  that  the 
report  generator  can  be  run  more  than  ’once  (e.g.,  after  an 
abend  or  to  produce  more  copies  of  the  reports)  . 

The  above  processing  scheme  would  make  program  restarts 
fairly  easy.  If  the  system  abended  during  the  first  pro¬ 
grams,  the  Output  Request  file  would  be  purged  of  all  entries 
beyond  the  last  request  number  of  the  last  run,  and  the  pro¬ 
grams  would  be  rerun.  If  an  abend  occurred  during  a  type  two 
program,  the  program  could  be  rerun  after  all  twos  in  the 
Output  Request  file  for  the  given  FEP  and  given  data  were 
changed  to  one,  and  after  all  entries  in  the  Output  Data 
file  for  the  given  FEP  and  date  were  purged.  A  type  three 
program  would  just  be  rerun  after  an  abend,  as  would  a  type 
four  program. 

For  the  above  reasons,  the  processing  scenario  mentioned 
above  is  suggested  for  implementation  by  the  LDCN . 
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OUTPUT  REPORTS 

INPUT  RECORDS 

LDCN  CPU  Utilization  Summary 

16  -  CPU  Utilization  Record 

System  Status  Report 

04  -  Status  Record 

Line  Notification  Report 

25  -  Excessive  Line  Error  Record 

Password  Failure  Report 

26  -  Password  Failure  Record 

Congestion  Report 

23  -  Congestion  Record 

User  Status  Plot 

Jo  1  -  Logon  Record 

|03  -  Logoff  Record 

System  Configuration 

05  -  System  Snapshot 

System  Signon-Signoff 

J01  -  Logon  Record 

|03.  -  Logoff  Record 

Traffic  Statistics  Plot 

06  -  Input  Message  Record 

Input  Message  Length  Histogram 

06  -  Input  Message  Record 

Output  Message  Length  Histogram 

07  -  Output  Message  Record 

CPU  Utilization  Plot 

16  -  CPU  Utilization  Record 

Buffer  Usage  Plot 

l08  -  Concentrator  Input  Record 

S09  -  Concentrator  Output  Record 

(l9  -  Buffer  Utilization  Record 

Output  Queue,  Plot 

20  -  Queue  Record 

Disk  Utilization  Plot 

18  -  Disk  Utilization  Record 

Table  5.1  -  OUTPUTS  AND  CORRESPONDING  INPUTS: 

SIMPLE  PROCESSING  METHODOLOGIES 
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OUTPUT  REPORTS 


LDCN  Response  Time  Report 
Response  Time  Report  by  System 
Response  Time  Report  by  Component! 

CPU  Utilization  Report 

CPU  Utilization  Report  by  Module 
CPU  Module  Access  Report 


Buffer  Usage  Report 


Output  Queue  Report 

LDCN  User  Status  Report 
User  Status  Report  by  System 

Disk  Utilization  Report 


INPUT  RECORDS 

08  -  15:  Response  Time  Statistical 
Records 

16:  CPU  Utilization  Record 
17:  CPU  Utilization  by  Module 

* 

08:  Concentrator  Input  Record 
<  09:  Concentrator  Output  Record 
19:  Buffer  Utilization  Record 

20:  Queue  Record 

01  -  03:  Configuration  Statistic 
Records 

18:  Disk  Utilization  Record 


Table  5.2  -  OUTPUTS  AND  CORRESPONDING  INPUTS: 

INTERMEDIATE  PROCESSING  METHODOLOGY 
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OUTPUT  REPORTS 

INPUT  RECORDS 

OTHER  DATA  NFEDEP 

‘“LDCN  Traffic  Summary  Plots 

— 

Data  from  Current  and 

-  Messages  Per  Week 

Past  LDCN  Status 

-  Av.  No.  of  Msgs/Hr 

Summaries 

System  Status  Exception 

04  -  Status  Record 

Equipment  or  Line 

Report 

Performance  Limit 

Output  Queue  Exception 

1  20  -  Queue  Record 

Maximum  Queue  Length, 

Report 

|  24  -  Overflow  Error  Record 

Current  Queue  Limit 

Buffer  Usage  Exception 

f 

08  -  Concentrator  Input 

No.  of  Buffers  in  Pool, 

Report 

Record 

Current  Buffer  Limit 

09  -  Concentrator  Output 

w 

Record 

19  -  Buffer  Utilization 

: 

Record 

! 

1 

^  24  -  Overflow  Error  Record 

'PU  Utilization  Exception 

16  -  CPU  Utilization  Record 

Utilization  Performance 

^-'Report 

Limit 

Disk  Utilization 

18  -  Disk  Utilization 

i 

Utilization  Performance 

i  Exception  Report 

'  Record 

Limit 

LDC  Traffic  Statistics 

06  -  Input  Message  Record 

Algorithm  to  go  froir 

Reports 

Concentrator,  Terminal 

-  Total 

ID,  and  Program  Type  to 

1  -  ASO 

Classification  for 

1  -  SPCC 

Inquiry,  Batch,  Real- 

-  By  System  and  Traffic 

Time,  Etc. 

p  Type 

Line  Error  Report 

22  -  Line  Error  Record 

Time-Out  and  Message 

r 

'  25  -  Excessive  Line  Error 

Error  Limits 

1 

Record 

j 

j-  Batch  Queue  Report 

21  -  Batch  Record 

Size  and  Time  Criteria 

Table  5.3  -  OUTPUTS  AND  CORRESPONDING  INPUTS: 

DATA  BASE  NEEDED  TO  STORE  OTHER  DATA 
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6.  SUMMARY 

This  report  presented  a  study  on  proposed  statistics  ru 
the  LDCN .  Section  2  gave  an  overview  of  the  LDCN,  statistics, 
and  network  management.  In  this  section,  the  manual  collection 
subsystem  of  the  LDCN  statistical  package  was  described. 
Sections  3,  4,  and  5  then  focused  on  the  computerized  sub¬ 
system.  Section  3  dealt  with  the  design  of  statistical 
reports  for  managers,  operators,  and  engineers.  In  all,  44 
reports  were  considered.  The  proposed  measurement  mechanisms 
to  obtain  statistical  data  were  presented  in  Section  4.  The 
approach  used  centered  on  a  history  tape  concept,  with  some 
26  statistical  records  being  pi. posed  for  collection  by  the 
LDCN.  Finally,  some  algorithms  to  convert  the  raw  data  into 
meaningful  statistics  were  given  in  Section  a. 
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A.l  INTRODUCTION 

This  appendix  presents  the  statistics  collected  by 
various  current  systems  in  order  to  manage  and  control  their 
operation  and  growth.  The  knowledge  of  these'  statistics 
served  as  background  information  for  the  derivation  of  the 
LDCN  statistics  proposed  in  the  previous  sections  of  tms 
document.  The  statistics  described  are  by  no  means  a  com¬ 
plete  treatise  on  the  subject,  nor  are  they  unique  to  the 
examples  mentioned.  These  examples,  however,  highlight  key 
ideas  that  were  used  to  derive  the  statistics  of  other 
systems  with  similar  functions  and  characteristics. 

The  first  set  of  statistics  described  is  from  the 
Philips  DS-714  computer  used  as  a  Telex  Switch.  The  DS-714 
system  collects  fairly  detailed  data  since  the  collection 
of  data  on  billable  calls  (company  revenue)  and  on  unsuc¬ 
cessful  calls  (lost  revenue)  is  very  important  to  the  survival 
and  growth  of  a  Telex  company.  This  first  section  thus  only 
focuses  on  the  data  collected  by  the  System. 

The  second  set  of  statistics  described  is  for  a  Com¬ 
munications  Control  System,  a  terminal  network  used  for 
customer  ordering,  inventory  control,  and  processing  of  com¬ 
pany  accounts.  This  system’s  statistics  are  relatively 
simple  and  straightforward,  while  the  statistics  presented 
for  the  S  network  of  a  major  insurance  company  are  somewhat 
more  complex.  The  procedures  used  in  monitoring  error 
statistics  in  the  NASDAQ  system  are  then  presented,  followed 
by  the  statistics  collected  in  a  Social  Security  Administration 
network.  Finally,  the  last  set  of  statistics  described  are 
those  of  the  ARPA  Network,  a  multipacket-transmission,  com¬ 
puter  network  system  sponsored  by  the  Advanced  Research 
Projects  Agency  (ARPA) . 
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A. 2  PS- 714  TELEX  SYSTEM 

A  Philips  DS-714  Telex  Switch  can  be  used  to  route  tele¬ 
graph  messages  in  the  United  States  or  between  the  United 
States  and  foreiqn  countries.  To  understand  some  cf  the 
statistics  collected  by  the  switch  in  performing  this  task, 
an  overview  of  the  Telex  operation  is  helpful.  Basically, 
after  a  call  arrives  at  a  Telex  Switch  over  an  input  circuit, 
the  switch  attempts  to  locate  and  seize  an  available  path  to 
the  requested  party.  Several  attempts  are  made  by  the  switch 
to  extend  (complete)  the  call.  If  none  of  the  extensions 
are  successful,  a  "busy  signal"  is  returned  to  the  caller; 
the  caller  may  then  hang  up  (causing  the  input  circuit  to  be 
disconnected  from  the  system)  or  place  another  call  request 
to  the  switch.  Billing  information  is  collected  on  suc¬ 
cessfully  completed  calls.  If  the  called  party  terminates 
the  call,  the  switch  disconnects  the  output  circuit  and 
allows  the  caller  to  place  another  call  request;  when  the 
caller  terminates  the  call,  both  the  input  and  output 
circuits  are  disconnected  from  the  switch. 

Three  types  of  reports  are  produced  on  a  Telex  Switch: 

a.  Accounting  and  billing  reports, 

b.  On-line  and  off-line  system  performance  reports, 
and 

c.  Management  information  reports  on  traffic  patterns 
and  business  growth. 

To  obtain  these  reports,  all  information  concerning  calls 
placed  through  the  DS-714  Telex  System  are  logged  on  a  history 
tape.  In  the  journalling  process,  the  data  is  first  logged 
on  a  disk;  after  a  specific  number  of  records  have  been 
written,  thev  are  grouped  into  a  block.  A  header  giving  the 
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date,  time,  and  block  size  is  then  appended  to  the  block, 
and  the  block  is  written  to  the  history  tape .  By  using  this 
scheme,  one  reduces  the  processing  associated  with  advancing 
to  a  particular  starting  time  by  skipping  over  blocks  instead 
of  individual  records. 

Table  A. 2.1  lists  the  minimum  information  required  for 
journalling  of  each  Telex  call.  On  input,  each  call  is  given 
a  reference  number  so  that  it  may  be  tracked  through  the 
system.  The  input  line  of  the  call  is  stored,  as  is  the  time 
(month,  day,  hour,  minute)  the  call  enters  the  system.  For 
accuracy  in  determining  the  total  time  of  the  call  in  the 
system,  the  connect  time  as  represented  by  the  system's 
clock  is  logged.  The  caller's  account  number  is  also  recorded; 
if  it  is  invalid,  the  reason  it  is  invalid  along  with  the 
caller's  response  to  this  fact  is  logged.  The  logging  of 
selection  information  for  the  called  party  is  similar  to 
that  for  caller  account  numbers.  For  each  output  attempt, 
the  output  line  and  the  time  it  was  seized  is  reported,  as 
is  the  disconnect  time  and  the  reason  for  an  unsuccessful 
attempt.  If  the  output  attempt  is  successful,  the  start  and 
end  of  the  billing  time  is  logged.  Finally,  the  disconnect 
time  and  the  originator  of  the  disconnect  is  recorded. 

In  addition  to  the  parameters  listed  in  Table  A. 2.1, 
system  status  records  are  logged  on  the  history  tape. 

Because  of  this,  the  DS-714  history  tape  is  composed  of  nine 
different  "logs".  Table  A. 2. 2  lists  the  nine  history  tape 
logs;  of  these,  the  first  three  contain  the  parameters  of 
Table  A. 2.1  for  messages  requiring  immediate  delivery. 

These  three  logs  are  a  major  source  of  statistics  for  the 
Telex  system;  thus  they  are  now  looked  at  in  more  detail. 

Table  A. 2. 3  shows  some  of  the  entries  in  the  Receive 
Selection  Log.  Of  these,  the  message  number,  input  bundle 
area  code,  and  circuit  number  are  used  to  identify  a  call 
from  a  geographic  area  such  as  the  U.  K.  or  France.  The 
time  the  call  request  is  received  is  given,  as  is  a  flag 
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indicating  whether  the  caller  originated  the  request  or  responded 
to  a  "next  message"  prompt  from  the  system  after  the  called 
party  disconnected.  The  log's  cancel  code  indicates  the  dis¬ 
position  of  the  call  during  the  receive  selection,  with  a 
zero  in  this  field  indicating  a  good  selection.  Table  A. 2. 4 
lists  the  other  input  cancel  codes.  Understanding  the  meaning 
of  these  cancel  codes  is  not  important;  however,  it  should  be 
noted  that  the  DS-714  recognizes  a  number  of  very  specific 
error  conditions  on  input.  This  recognition  is  important 
to  a  Telex  company  because  an  unsuccessful  call  is  lost 
revenue  to  them.  As  such,  the  company  needs  to  know  what 
errors  are  due  to  the  user  and  what  errors  are  due  to  the 
system  so  that  these  problems  can  be  corrected  whenever 
possible,  thereby  increasing  revenue. 

The  relevant  entries  of  the  Call  Extension  Log  are 
shown  in  Table  A. 2. 5.  The  message  number  and  input  bundle 
and  circuit  relate  this  log  to  the  corresponding  Receive 
Selection  Log.  Output  bundle  and  circuit  information  is 
given.  The  duration  of  the  call  extension  is  obtained  by 
subtracting  the  end  time  from  the  seize  time,  and  the  dis¬ 
position  of  the  extension  is  given  by  the  cancel  code. 

Table  A. 2. 6  lists  the  output  cancel  codes  for  a  call  extension 
log;  once  again,  understanding  the  meaning  of  the  various 
codes  is  not  as  important  as  recognizing  that  a  company 
needs  to  know  about  specific  errors  in  order  to  improve 
service  and  increase  revenue.  A  final  point  should  be  noted 
about  the  call  extension  log.  Currently,  the  count  of  which 
attempt  a  particular  call  extension  is  is  not  recorded  by 
the  DS-714.  Thus  to  determine  the  number  of  extensions  per 
call,  call  extension  logs  must  be  matched  to  their  corres¬ 
ponding  receive  selection  logs.  Since  the  processing 
associated  with  the  matching  of  records  must  be  performed 
for  other  statistics,  the  omission  of  the  count  is  not 
important;  however,  for  other  systems,  processing  time  can 
be  saved  by  recording  this  value. 
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Table  A. 2. 7  shows  the  entries  of  interest  in  the  Regular 
Call  Record.  The  message  number,  input  bundle,  and  circuit 
is  again  given,  as  is  the  output  bundle  and  circuit  of  the 
last  call  extension.  Billing,  cancel  code,  and  disconnect 
information  is  also  given.  The  regular  call  record  is  com¬ 
plete  for  billing  runs;  however,  it  could  be  considered  in¬ 
complete  for  statistical  purposes.  A  more  complete  call 
record  would  contain  the  receive  time  interval  timer  and  FST 
flag  from  the  receive  selection  log,  the  end  interval  timer 
from  the  last  call  extension  log  for  the  message,  and  the 
count  of  which  attempt  the  last  call  extension  was.  This 
new  log  would  eliminate  the  matching  of  receive  selection 
logs  to  regular  call  records  to  obtain  total  time  for  a  call. 
In  addition,  the  length  of  time  an  originator  would  wait  for 
a  call  connect  before  disconnecting  could  be  easily  obtained, 
as  well  as  the  extension  at  which  disconnection  occurs.  All 
these  statistics  are  necessary  in  the  monitoring  of  Telex 
lines;  to  obtain  them  by  a  matching  process  is  not  always 
cost  effective.  However,  in  this  case,  the  format  of  the 
regular  call  record  is  justified.  To  create  the  above 
"extended"  record,  either  the  values  from  each  component 
log  would  have  to  be  carried  in  the  message  header,  or  the 
values  would  be  stored  on  disk  and  the  DS-714  would  have  to 
match  these  values  to  the  regular  call  record  in  a  real-time 
mode.  After  analysis,  it  was  determined  the  processing  time 
for  an  off-line  matching  of  records  was  more  appropriate 
than  the  additional  core  required  for  either  of  the  above 
cases;  in  addition.  Philips  felt  that  off-line  processing 
was  more  cost-effective  than  the  on-]ine  processing  required 
in  the  second  case.  Thus,  in  trading  off  various  factors. 
Philips  went  with  the  above  call  record. 

The  many  complex  outputs  produced  by  the  DS-714  Telex 
System  statistical  programs  will  not  be  discussed  here. 
However  ,  it  should  be  noted  that  the  statistical  programs 
are  useless  without  the  raw  data  from  the  history  tapes.  By 
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having  the  DS-714  record  statistics  as  they  occur.  Philips 
has  potential  problems  associated  with  the  matching  of  logs 
to  obtain  certain  statistics.  Some  of  these  problems  are 
avoided  by  having  certain  logs,  like  the  regular  call  record, 
contain  all  information  needed  for  a  billing  run;  in  addition, 
logs  like  the  regular  call  record  can  be  used  to  determine 
the  traffic  passing  through  the  system.  These  types  of 
programs  are  run  on  a  daily  basis;  programs  that  require  the 
matching  of  logs  to  monitor  network  performance  (e.g.,  line 
utilization  or  the  time  spent  in  servicing  a  call)  are  run  on 
a  less  frequent  periodic  basis  (e.g.,  weekly,  monthly,  or 
quarterly) . 
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Input  Parameters  (For  Each  Call) 

a)  Line  number,  (sufficient  information  to  define  the  hardware  used 
for  the  call) . 

b)  Month,  day,  hour,  minute. 

c)  Time  "Call  Request"  was  received.*  (Start  of  Input  line  holding 
time) . 

d)  Call  reference  number. 

Calling  Network  Supplied  Parameters 

a)  Answerback  or  number  of  calling  subscriber  (if  information  not 
acceptable,  the  type  of  canned  message  sent  and  the  subscriber's 
response) . 

b)  Selection  (if  information  not  acceptable,  the  type  of  canned 
message  sent  and  the  reselectlon)  .  If  the  call  is  handled  by  an 
operator,  the  selection  given  by  the  operator,  if  any. 

Output  Parameters  (For  Each  Output  Attempt) 

a)  Line  number  (sufficient  information  to  define  the  hardware  and 
route  used  for  the  attempt) . 

b)  Time  line  seized.* 

c)  Response  and  time*  of  disconnect  jar 

d)  Aiisweroack  of  called  party  and  time  of  call  connect. 

*Inteinal  System  Time  in  Seconds 


Table  A. 2.1  -  PARAMETERS  THAT  MUST  BE  STORED  IN  THE  HISTORY  TAPE 
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Call  Duration  Part  meter-  (For  Successful  Calls) 

a)  Start  time  of  billing  duration.*  (If  this  time  cannot  be  derived 
from  the  time  of  the  call  connect) . 

b)  End  time  of  billing  duration.* 

Call  Disconnect  Parameters  (For  Each  Call) 

a)  Origin  and  type  of  disconnect. 

b)  Time  disconnect  signal  received.* 

c)  Time  output  line  disconnected.* 

d)  End  time  of  billable  duration.* 

e)  Time  input  line  disconnected.* 

f)  Month,  day,  hour,  minute. 


*Internal  System  Time  in  Seconds 


Table  A. 2.1  -  (Continued) 
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Lor  Name  Contains 

Receive  Selection  Log  Information  on  the  call  request. 

Call  Extension  Log  Information  on  each  call  extension. 

Regular  Call  Log  Information  on  a  successfully  completed 

call. 

Safe  EOM-In  Log  Information  on  a  store  and  forward 

message  inputted  into  the  switch. 

Safe  EOM-Out  Log  Information  on  the  delivery  attempt  of 

a  store "and  forward  message. 

Disconnect  Log  Information  on  the  disconnection  of  a 

caller  who  does  not  stop  transmitting 
characters . 

False  Seizure  Log  Information  on  the  seizure  of  an  input 

line  without  any  call  request  being  made. 

Startup-Restart-  Information  on  the  data  and  time  of  a 

Switchover  Log  system  startup,  restart,  or  switchover. 

Text  Billing  Log  Information  on  the  first  characters  of 

a  text  billing  message. 


Table  A. 2. 2  -  LOGS  WRITTEN  ON  THE  HISTORY  TAPE 
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Telex  Message  Number  -  for  internal  call  identification. 

a)  Input  Bundle  Area  code, 

b)  Input  Circuit  Number. 

a)  Receive  Time  (Month,  Day,  Hour,  Minute). 

b)  Receive  Time  Interval  Timer  -  the  rightmost  18  bits  of  the  one 
second  system  interval  clock. 

► 

O-Receive  Time  is  the  time  a  solicitation  for  the  next 
message  was  sent  to  the  caller. 

c)  FST  = 

1-Receive  Time  is  the  time  the  calling  party  connected 
to  the  system. 

Cancel  Code  -  the  reason  the  request  was  "disposed  of"  before  a  call 
extension  could  occur. 


Table  A. 2. 3  -  RECEIVE  SELECTION  LOG  ENTRIES  FOR  STATISTICAL  ANALYSIS 
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0-Good  Selection 

1- Registered  Numbers  Not  Allowed  With  Associated  Option  Code 

2- Selection  Error  (for  all  other  errors) 

3- Program  Illogical  Error 

4- Area  Code  Barred 

5- lnvalid  F.69  Code 

6- Unknown  Area  Code 

7- Corapare  Failure  on  Special  F.69  Code 

8- Forbidden  Digit  Detected 

9- Abbreviated  Code  Unassignable 

10- Abbreviated  Code  Invalid  for  Associated  Answerback 

11- Too  Many  Selection  Digits 

12- No  Route  to  Directly  Connected  Subscriber 

13- No  Route  to  Directly  Connected  Subscriber  (no  disc  in  system) 

14-  Two  Option  Codes  in  Selection 

15- Option  Code  Barred 

16- Area  Code  Not  Serviced 

17- Continuous  Input  From  Caller 

18- Caller  Disconnected 

19- Calle  -  Cancelled  with  Five  L's 

20- Disto  tion  Analyzer  Not  Available 

21- No  Va  id  Selection  Characters  Input 

22-  Insufficient  Resources,  Multiple  Number  Request 

23- No  Match  on  Registered  Number  Look-Up 

24- No  Match  on  Registered  Number  Look-Up  (no  disc) 

25- No  Match  on  Dial  Code  Related  to  Registered  Number 

26- No  Match  on  Dial  Code  Related  to  Registered  Number  (no  disc) 

27- Not  Enough  Blocks,  Capture  Data  Option  Code 

28-  (Not  Used) 

29- Retrieval/ Supervisor  Command  Parameter  Error 

30- Caller  Responded  "NG"  to  Called  Answerback  for  SAFE  Input 

31- Security  Code  Violation  for  Retrieval 

32- System  Critical  Level  Reached  for  SAFE  Traffic 

33- Called  Circuit:  No  Answerback  Received 
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34- Called  Circuit  Answerback  Error 

35- Barrec1  Collect  Call 

36- Caller  Circuit  Error 

37- Caller  Fails  to  Respond  With  OK  or  NG  to  SAFE  Answerback;  After  Second 
Request 

38- Circuit  is  Busy  for  "Place  Call  on  Specified  Circuit"  Option  Code 

3 9-  II legal  Call  Attempt 

40- Illegal  Call  Attempt 

41- SAFE  Option  to  a  Barred  Destination 

42- Hour,  Minute  Field  Error  -  Special  Delivery,  Book 

43- TELEX  Number  Field  Error  -  Cancel,  Request  for  Credit 

44- Circuit  Number  Error  (Place  Call  on  Specified  Circuit) 

45- No  Match  on  Answerback  Look-Up 

46- No  Match  on  Answerback  Look-Up  (no  disc) 

47- Input  Bundle  Time-Out,  Prior  to  Cross  Connect 
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Telex  Message  Number 

a)  Input  Bundle  Area  Code 

b)  Input  Circuit  Number 

a)  Output  Bundle  Area  Code 

b)  Output  Circuit  Number 

a)  Output  Circuit  Seize  Time  (Month,  Day,  Hour,  Minute) 

b)  Output  Circuit  Seize  Time  Interval  Timer 

End  Interval  Timer  -  the  time  a  call  connect  was  received  or  the 

circuit  disconnect  time  for  incomplete  extensions. 

Cancel  Code  -  the  reason  the  call  extension  was  not  successful. 


Table  A  2.5  -  CALL  EXTENSION  LOG  ENTRIES  FOR  STATISTIC^.  ANALYSIS 
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0-Good  Extension 

1- Occupied 

2- OCC  Received  (semi-manual  extension) 

3- No  Circuits 

4- NC  Received  (semi-manual  extension) 

5- ABS  Received 

6- ABS  Received  (semi-manual  extension) 

7-  Improper  Answerback 

8- NA  Received 

9- DER  Received  (semi -manual  extension) 

10- NA  Received  (semi-manual  extension) 

11- Subscriber ' s  File  Changed 

12- NCH  Received  (semi-manual  extension) 

13- NP  Received  (semi-manual  extension 

14- Country  Name  Not  in  File  (with  disc) 

15- Country  Name  Not  in  File  (without  disc) 

16- Invalid  Input  (Semi-manual  extension) 

17- Second  Attempt  Failure  (semi-manual  extension) 

18- Caller  Circuit  Disconnected 

19- Five  L's  Received 

20- Called  Circuit  Error 

21- No  Available  Route 

22- NC  Received 

23- DER  R(  ceived 

24- No  Ca  1  Confirm 

25- No  PTS 

26- Call  Connect  Timeout 

27- OCC  Received 

28- Called  Circuit  Disconnected 

29- NP  Received 

30- NCH  Received 

31- Call  Back  Look-Up  Failure 

32- System  Critical  Level  Reached 

33- Head-On  Collision 
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34- Answerback  Mismatch 

35- DER  Received  After  Call  Connect 

36- Caller  Circuit  Error 

37- No  Data  Connect 

38- No  DLO 

39- Disconnect  Alarm 

40- Abandon  Call 

41- Semi-Manual  Error,  Requiring  a  SWBD 

42- DSUB  Unavailable,  But  Not  Busy  With  Call 

43- DSUB  Called  Circuit  Error 

44- DSUB  Call  Connect  Time-Out 

45- (Not  Used) 

46-  (Not  Used) 

47- Input  Bundle  Time-Out,  Prior  to  Cross  Connect 


Table  A. 2.6  -  (Continued) 
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1.  Telex  Message  Number 

2.  a)  Input  Bundle  Area  Code, 

b)  Input  Circuit  Number. 

3.  a)  Output  Bundle  Area  Code, 

b)  Output  Circuit  Number. 

A.  Billing  Start  Time  Seconds  Counter 

5.  a)  End  Billing  Time  Seconds  Counter 

b)  BT  -  if  BT  is  not  zero,  then  the  end  time  counter  is  valid 

6.  FST  -  if  FST  is  one,  then  the  receive  time  is  placed  in  the  billing 
start  and  end  time 

7.  a)  Cancel  Code 

{0-Cancel  Code  refers  to  the  call  rpquest 
1-Cancel  Code  refers  to  the  call  extension 

8.  Originator  Disconnect  Time  Seconds  Counter 

9.  Called  Party  Disconnect  Time  Seconds  Counter 

10.  DIS  -  gives  the  type  of  disconnect  for  a  call 

11.  Actual  Time  the  log  was  created  (Month,  Day,  Hour,  Minute) 


Table  A. 2. 7  -  REGULAR  CALL  RECORD  ENTRIES  FOR  STATISTICAL  ANALYSIS 
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A.  3  THE  COMMUNICATIONS  CONTROL  SYSTEM 


Many  large  manufacturing  firms  have  in-house  computer 
networks.  One  such  system  is  located  in  an  East  Chicago, 

Indiana  plant.  Called  the  Communications  Control  System  (CCSYS) 
primary  terminal  system,  the  network  has  a  data  base  manage¬ 
ment  system  which  permits  on-line  accessing  and  updating  of 
data  on  customer  orders  and  their  processing,  inventory  con¬ 
trol,  and  company  accounts.  Like  the  DS714  Telex  System, 
statistics  for  the  CCSYS  primary  terminal  system  are  contin¬ 
ually  collected  on  a  history  tape.  Some  of  the  statistical 
records  collected  on  the  tape  are: 

a.  System  configuration  records  list  all  terminals  that 
are  currently  under  CCSYS  control.  System  config¬ 
uration  records  are  produced  as  a  result  of  an 
operator  request  for  configuration  status,  and 
contain  the  time  (hour,  minute,  second)  and  date 
(month,  day,  year)  the  record  was  created,  the  line 
number  and  terminal  identifier  for  an  active  term¬ 
inal,  and  the  type  of  terminal  (CRT  or  teletypewriter) . 

b.  A  line  status  record  is  produced  each  time  the  CCSYS 
operator  drops  a  line  from  the  system  or  reinstates 
a  line  to  the  system.  The  record  contains  the  time 
and  date  of  the  action,  as  well  as  the  line  number 
and  line  status  due  to  the  action  (up  or  down) . 

c.  An  application  sign-on/off  record  is  produced  each 
time  a  terminal  user  enters  a  valid  application. 

(An  application  in  the  CCSYS  is  a  set  of  COBOL 
programs  that  perform  a  series  of  related  tasks.) 

The  sign-on/off  record  contains  the  terminal  iden¬ 
tifier  and  application  name,  the  time  and  date  of 
the  activity,  and  the  activity  (sign-on  or  sign-off). 


fc 


d.  An  application  program  record  is  produced  each  time 
a  COBOL  program  is  executed.  This  record  contains 
the  name  of  the  program  being  executed,  its  core 
requirement  in  bytes,  the  application  it  is  running 
under,  the  terminal  which  is  using  it  and  the  start 
time  and  date  and  the  end  time  and  date  of  the  pro¬ 
gram's  execution.  In  addition,  the  number  of  unsuc¬ 
cessful  loads  of  the  program  for  this  execution  due 
to  insufficient  core  is  recorded;  from  this,  one  can 
determine  when  core  becomes  a  system  bottleneck. 
Finally,  the  application  program  record  indicates 
whether  the  program  was  loaded  by  a  CCSYS  special 
control  feature. 

e.  A  terminal  I/O  record  is  produced  each  time  a  read 
or  write  operation  is  completed  to  a  terminal.  This 
record  contains  the  time  and  date  of  the  operation, 
the  type  of  operation  (read  or  write)  ,  the  name  of 
the  format  that  was  used,  the  program  that  initiated 
the  I/O,  the  length  (in  bytes)  of  the  data  trans¬ 
mitted,  and  the  segment  number  of  the  input  or  out¬ 
put.  This  record  also  contains  the  terminal  iden¬ 
tifier  and  application  name. 

f.  Each  time  a  terminal  abends,  an  abend  record  is  pro¬ 
duced  on  the  history  tape.  This  record  contains  the 
name  of  the  abending  terminal,  its  line  number,  the 
time  and  date  of  the  abend,  the  abend  type  (system 
or  user)  ,  and  the  abend  completion  code . 

g.  Core  allocation  records  list  whether  the  various 
CCSYS  core  regions  are  allocated  or  free.  These 
records  also  contain  the  date  and  time  the  record 

was  created,  as  well  as  the  region's  starting  address, 
ending  address,  and  size. 
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The  CCSYS  data  reduction  program  produces  reports  from 
the  history  tape.  Control  cards  for  the  program  specify  the 
time  period  for  which  reports  are  desired  and  the  desired 
reports.  Ten  reports  may  be  produced  by  the  program: 

a.  System  Configuration  Report 

b.  Line  Status  Report 

c.  Sign-On/Off  Report 

d.  Application  Program  Report 

e .  Terminal  I/O  Report 

f.  Abend  Report 

g.  Frequency  of  Programs  Report 

h.  Terminal  I/O  Frequency  Report 

i.  Line  I/O  Frequency  Report 

j .  Frequency  of  I/O  Formats  Report 

The  first  si <  reports  are  simply  a  line  per  record  listing 
of  the  raw  data  records.  Thus,  a  request  for  these  reports 
over  a  time  period  exceeding  one  hour  may  result  in  a  voluminous 
report  when  the  CCSYS  system  is  heavily  active  during  the 
specified  period.  Figures  A.3.1-A.3.3  show  three  of  these 
six  reports.  Figure  A. 3.1  shows  the  System  Configuration 
Report;  the  "P"  in  the  type  field  refers  to  a  hardcopy  printer, 
while  a  "T"  refers  to  a  CRT  Tube.  Figure  A. 3. 2  shows  the 
Terminal  I/O  Report.  The  "W"  in  this  report  refers  to  a 
write  (output)  operation,  while  an  "R"  refers  to  a  read 
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(input)  operation.  Finally,  the  Application  Program  Report 
is  presented  in  Figure  A. 3. 3.  It  should  be  noted  that  the 
"Seconds  Used"  field  in  this  report  is  not  part  of  the 
application  program  record,  but  is  calculated  by  the  statis¬ 
tical  program  from  the  "Start  Time"  and  End  Time"  fields. 

Rather  than  deal  with  line-by-line  data,  CCSYS  manage¬ 
ment  can  obtain  four  summary  reports  from  the  statistical 
program.  The  first  is  the  Frequency  of  Programs  Report, 
which  lists  each  program  executed  during  a  given  hour  only 
once.  For  each  program  listed,  the  total  number  of  executions 
for  the  hour  are  given,  as  is  the  total  execution  time. 

The  average  execution  time  is  also  given;  this  value  is 
obtained  by  the  integer  division  of  the  total  execution 
time  by  the  total  number  of  executions.  Finally,  the  pro¬ 
gram  size  and  total  number  of  unsuccessful  program  loads  are 
given  for  each  entry.  Figure  A. 3. 4  shows  a  sample  report 
output . 

Two  summary  reports  are  very  similar  in  nature.  The 
Terminal  I/O  Frequency  Report  (Figure  A. 3. 5)  lists  each 
terminal's  I/O  activity  on  an  hourly  basis.  The  total 
number  of  reads  and  writes  are  given  for  each  terminal,  as 
is  the  total  number  of  bytes  inputted  and  outputted. 

The  Lire  I/O  Frequency  Report  (Figure  A. 3. 6)  groups  the 
above  terminal  data  by  line  identifier  and  then  reports  this 
I/O  activity  for  each  line.  The  final  summary  report  is  the 
Frequency  of  I/O  Format  Report.  This  report  lists  the  number 
of  times  each  format  is  used  on  an  hourly  basis,  along  with 
the  average  message  length.  Figure  A. 3. 7  shows  a  sample 
Frequency  of  I/O  Format  Report. 

The  statistics  collected  by  the.  ._CCS  YS  are  fairly  simple 
and  straightforward.  Other  systems  collect  more  complex  data; 
thus  we  will  now  look  at  one  of  these  systems. 
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DATE  TIME  TYPE  FORMAT  LENGTH  SEGMENT  NO.  TERMINAL  APPLICATION  PROGRAM 
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PROGRAM 

SIZE 

NO 

TOTAL 

SEC 

AVE 

SEC 

TOT 

RETRIES 

DATE 

HOUR 

A0240370 

65576 

20 

39 

1 

0 

12  02  74 

13 

A0240380 

28720 

14 

10 

0 

0 

12  02  74 

13 

A0240390 

27728 

14 

12 

0 

0 

12  02  74 

13 

A0240400 

25512 

11 

2 

0 

0 

12  02  74 
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TERMINAL 

NO. 

READS 

NO. 

WRITES 

BYTES 

IN 

BYTES 

OUT 

TOT 

NO. 

TOTAL 

BYTES 

DATE 

HOUR 

LOBOOOOl 

8 

8 

347 

5657 

16 

6004 

12  02  74 

13 

L0B20001 

31 

32 

2202 

40426 

63 

42628 

12  02  74 

13 

L06A4051 

8 

9 

888 

9125 

17 

10013 

12  02  74 

13 

L06A4052 

8 

9 

398 

6154 

17 

6552 

12  02  74 

13 

Figure  A. 3. 5  -  TERMINAL  I/O  FREQUENCY  REPORT 
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LINE 

NO. 

READS 

NO. 

WRITES 

BYTES 

IN 

BYTES 

OUT 

TOT 

NO. 

TOTAL 

BYTES 

DATE 

HOUR 

LOBO 

8 

8 

347 

5657 

16 

6004 

12  02  74 

13 

L0B2 

31 

32 

2202 

40426 

63 

42628 

12  02  74 

13 

L06A 

28 

32 

1844 

24544 

60 

26388 

12  02  74 

13 

L06C 

26 

33 

2053 

28056 

59 

30109 

12  02  74 

13 

FORMAT 

TYPE 

LENGTH 

NUMBER 

DATE 

HOUR 

A8040020 

W 

915 

9 

12  02  74 

13 

A8040020 

R 

23 

8 

12  02  74 

13 

A8040040 

W 

1355 

9 

12  02  74 

13 

A8040040 

R 

35 

8 

12  02  74 
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A. 4  THE  S  NETWORK  REPORTS 


The  S  Network  connects  terminals  in  an  insurance  company's 
branch  offices  to  an  IBM  370  computer  on  the  east  coast.  Data 
describing  newly  written  auto  and  homeowners  policies  and 
updates  to  the  descriptions  of  existing  policies  are  input 
at  the  terminals,  and  information  about  these  policies  is 
returned  to  the  branch  offices  as  acknowledgements  and 
forms.  In  addition,  the  S  Network  handles  the  transmission 
of  administrative  messages  between  branch  offices  and  the 
central  computer  site. 

The  traffic,  reliability,  response  time,  and  system 
statistics  collected  by  the  S  Network  are  used  to  manage  the 
system's  operation  and  growth.  Together,  these  statistics 
form  a  complete  picture  of  the  system  for  purposes  of  analysis, 
maintenance,  and  future  planning.  Let  us  now  look  at  some  of 
these  reports  in  more  detail . 

Network  traffic  statistics  are  used  in  system  response 
time  and  capacity  analyses,  and  to  make  meaningful  projections 
on  system  growth.  The  S  Network  reports  system  traffic  sta¬ 
tistics  on  a  per  terminal  per  day  basis,  giving  such  infor¬ 
mation  as: 

a.  The  number  of  messages  that  originated  from  a 
terminal , 

b.  The  average  message  length, 

c.  The  total  number  of  characters  transmitted  from 
each  terminal. 

Similar  traffic  characteristics  are  reported  for  messages 
destined  for  each  terminal.  Figure  A. 4.1  shows  a  sample 
traffic  report.  The  number  of  messages  into  and  out  of  the 
processor  is  also  given  on  this  report,  as  is  the  number  of 
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I/O  errors  for  the  day.  Finally,  traffic  reports  on  a  per 
line  basis  can  be  used  to  produce  line  utilization  statistics. 
The  S  Network  thus  produces  a  line  traffic  report  (Figure  A. 4. 2) 
listing  the  terminals  which  utilize  the  same  line  and  their 
traffic  characteristics. 

A  necessity  in  the  collection  of  system  statistics  is 
the  monitoring  of  system  error  performance  since  knowing 
the  frequency  of  terminal  errors,  line  errors,  and  operator 
errors  is  important  for  network  maintenance.  The  S  Network 
provides  a  daily  error  report  on  a  per  line  basis.  This 
report  lists  the  number  of  errors  which  have  occurred  during 
different  time  segments  of  message  handling  such  as: 

•  Origination  error 

•  Destination  error 

•  Data  Check  Addressing  error 

•  Data  Check  error 

•  Data  Check  Polling  error 

A  typical  summary  error  report  is  shown  in  Figure  A. 4. 3.  On 
this  report,  note  that  total  origination/destination  message 
traffic  is  given  along  with  the  above  mentioned  errors. 

When  the  traffic  volume  at  each  office  is  known,  as  well 
as  the  mean  values  for  positive  polling  and  addressing  time, 
and  the  offices  on  each  multidrop  line,  then  line  utilization 
can  be  computed.  The  S  Network  reports  current  line  uti¬ 
lization  in  time  frames  of  15  minutes  for  the  active  periods 
of  the  day.  The  number  of  messages,  number  of  data  charac¬ 
ters  and  the  percent  of  line  utilization  is  given,  as  is  the 
average  and  peak  hour  utilization.  This  report  is  shown  in 
Figure  A. 4 . 4 . 
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Finally,  response  time  statistics  indicate  which  areas 
in  the  system  are  under-utilized  or  over-utilized  and  thus 
highlight  those  areas  in  need  of  change.  System  response 
time  measurements  also  add  to  an  overall  understanding  of 
the  system's  throughput  capability  and  the  nearness  of  the 
current  loading  to  the  system's  capacity.  The  S  system  has 
a  comprehensive  response  time  report .  The  central  processor 
of  the  network  operates  on  two  queues  (SAFA,  SAFB)  .  SAFB  is 
a  low  priority  queue  for  of f ice-to-off ice  type  messages  which 
can  be  held  for  deferred  processing.  Roughly  half  of  the 
inputs  to  the  S  Network  are  handled  in  this  way.  SAFA  is  a 
real-time,  high  priority  queue.  Some  of  the  S  system's 
response  time  components  are: 

•  Bid  to  poll  time 

•  Queue  In  to  Receive  In  time 

•  Receive  In  to  Receive  Out  time  (RIRO) 

•  Queue  In  to  Receive  Out  time  (QIRO) 

•  SAFA  transactions  per  min.  (SAFA  TRX/MIN) 

•  SAFB  transactions  per  min.  (SAFB  TRX/MIN) 

•  SCAN  transactions  per  min.  (SCAN  TRX/MIN) 

Figure  A. 4. 5  shows  a  typical  S  system  measurement  report. 
In  this  report,  response  time  components  are  listed  on  an 
hourly  basis.  The  average  number  of  transactions  per  queue 
is  also  recorded,  as  well  as  total  transactions  per  CPU. 
Transactions  per  channel  and  per  line  are  also  recorded. 
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Many  other  systems  have  similar  statistics.  The  NASDAQ 
System  is  such  a  system;  in  addition,  the  error  statistic 
aspect  of  this  system  was  studied  by  NAC.  Let  us  now  look  at 
the  error  statistics  of  the  NASDAQ  System. 
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Figure  A. 4.1  -  NETWORK  TRAFFIC  REPORT 


m 

m 

O 

CN 

r-H 

VO 

ON 

CN 

oo 

CO 

co 

m 

vO 

ON 

o 

St 

CO 

00 

9, 

•» 

* 

9k 

in 

m 

o 

r-H 

st 

CN 

00 

co 

CN 

co 

in 

cN 

m 

m 

vO 

#> 

•— l 

<* 

m 

*—♦ 

CO 

vO 

CN 

CN 

w—i 

CN 

r—4 

<3“ 

CN 

o 

<T 

ON 

o 

St 

1  VO 

*-< 

O' 

•» 

* 

9 

9 

o 

00 

ON 

CO 

<r 

CN 

CN 

ON 

00 

St 

CN 

H 

00 

CN 

H 

r> 

ON 

H 

o 

CN 

co 

St 

•cr 

l, 

<r 

ON 

co 

m 

o 

oo 

St 

CN 

<r 

o 

9\ 

9 

o 

m 

H 

CO 

rH 

rH 

m 

n- 

H 

CN 

co 

li 

CN 

r-4 

CO 

00 

CO 

q 

o 

o 

< 

< 

o 

CO 

Q 

CM 

w 

2 

M 

i 


Figure  A. 4. 2  -  TCAM  STATTSTICS  PER  LINE 
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Figure  A. 4. 3  -  SUMMARY  ERROR  REPORTS  PER  LINE 
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Figure  A. A. 5  -  SYSTEM  MEASUREMENT  S  MMAP  REPORT 
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A .  5  NASDAQ  SYSTEM 


The  National  Association  of  Securities  Dealers  Automated 
Quotations  (NASDAQ)  System  is  an  interconnection  of  computers, 
communications  devices,  and  terminals  designed  for  the 
collection  and  distribution  of  real-time  quotations  for  the 
Over-the-Counter  Securities  Market.  Low,  medium,  and  high 
speed  communication  lines  tie  these  devices  to  the  NASDAQ 
Central  Processing  System  in  Trumbull,  Connecticut  which  is 
configured  with  UNIVAC  1108  processors.  The  terminals  are 
connected  to  over-the-counter  control  unitsl  (OCU's)  located 
in  subscriber  offices.  These  control  units  are  connected  on 
multidrop  regional  lines  to  data  concentrators  located  in 
Atlanta,  Chicago,  New  York,  and  San  Francisco.  These  con¬ 
centrators,  configured  with  Honeywell  DDP-516  processors, 
are  connected  to  the  central  processing  system  by  trunk  lines. 

Day-to-day  management  of  the  regional  circuits  include 
the  obvious  concern  as  to  actual  performance.  In  this 
regard,  the  concentrators  and  central  processors  are  pro¬ 
vided  with  software  for  monitoring  short  and  long  term  error 
conditions.  The  short  term  monitoring  conditions  are  aimed 
at  detecting  errors  at  OCU's  and  on  regional  and  trunk  cir¬ 
cuits  and  provide  an  alarm  as  the  result  of  indicated  mal¬ 
functions.  On  a  long  term  basis,  network  management  involves 
monitoring  the  usage  of  these  circuits  as  it  relates  to  the 
growth  of  terminals  on  the  circuit.  The  aim  of  these  efforts 
is  the  maintenance  of  an  efficient  network  configuration 
both  from  the  service  standpoint  and  from  the  circuit  cost 
standpoint.  The  tools  available  for  this  purpose  are  pro¬ 
grammatic  in  nature.  Other  than  the  measurement  of 
response  time,  which  is  done  by  hardware  on  a  selective 
basis,  actual  circuit  usage,  including  an  occupancy  measure¬ 
ment,  as  available  by  extracting  data  from  records  maintained 
as  part  of  the  system.  V7ith  regard  to  trunk  circuits,  the 
concentrator  program  is  used  to  monitor  the  real-time 
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activity  in  order  to  provide  an  alarm  under  conditions  of 
deteriorated  performance. 

A .  5 . 1  Summary  of  NASDAQ  Error  Monitoring  Procedures 

The  procedures  used  in  the  NASDAQ  system  to  report 
short-term  or  long-term  error  rates  on  both  regional  and 
trunk  circuits  are  summarized  below. 

A . 5 . 1 . 1  Regional  Circuits 

a.  QCU  Polling  Function 

If  three  consecutive  "no  responses"  (130  ms  time¬ 
outs)  to  polls  occur,  the  concentrator  initiates 
the  typeout: 

"ERROR  LINE  XX  OCU  Y" 

b.  Transmit  Function 

If  transmission  is  not  completed  for  any  message 
that  has  been  set  up,  the  concentrator  initiates 
the  typeout: 

"O/P  STALL  LINE  XX" 

c.  Short-Term  Error  Rates 

A  counter  is  initialized  to  the  value  240  every  five 
minutes.  This  counter  is  incremented  and  decremented 
by  correct  and  incorrect  messages,  respectively. 

When  the  count  becomes  negative ,  the  concentrator 
initiates  the  typeout: 

"ERRORS  LINE  XX" 
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Rules  for  incrementing  and  decrementing  are: 

1.  Increment  by  1  for  each  complete  Reply  message 
transmitted  to  an  OCU. 

2.  Increment  by  1  for  each  set  of  32  Pell  -  No  Query 
sequences  on  a  circuit. 

3.  Decrement  by  80  for  bad  parity  in  a  Query  or  No 
Query  (EOT)  response  to  a  poll;  no  Start  Code 
(SOH)  ;  no  End  Code  (EXT)  ;  or  when  the  audit 
bit  in  the  A2  character  of  the  Query  header  is 
set. 

d.  Long-term  Error  Rates 

An  overlay  program  is  available  to  produce  the 
following  daily  statistics: 

1.  Number  of  valid  queries, 

2.  Number  of  responses, 

3.  Number  of  No  Query  (EOT)  responses,  and 

4.  Number  of  No  Responses  "(Time-Outs)  . 

A. 5. 1.2  Trunk  Circuits 


a .  Transmit  Function 

If  transmission  is  not  completed  for  any  message 
that  has  been  set  up,  the  concentrator  initiates 
the  typeout : 


"O/P  STALL  TRUNK  XX" 
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b.  Short-Term  Error  Rates 

1  •  At  Concentrator 

A  Counter  is  initialized  to  the  value  240  every 
five  minutes.  This  counter  is  incremented  and 
decremented  by  correct  and  incorrect  messages, 
respectively.  When  tae  count  becomes  negative, 
the  concentrator  initiates  the  typeout: 

"ERRORS  TRUNK  X" 

Rules  for  incrementing  and  decrementing  are: 

a.  Increment  by  1  for  each  complete  message 
sent  to  CPC. 

b.  Decrement  by  80  for  each  of  the  following 
causes : 

•  Stalled  Trunk  condition, 

•  Trunk  time-out, 

•  Bad  header  in  reply  from  1108,  and 

•  Incorrect  parity  in  reply  from  1108. 

2.  At  1108  CPU 

a.  Whenever  a  series  of  25  consecutive  input 
messages  are  received  in  error  over  the 
trunk,  the  Master  Terminal  Printer  types: 

"CLT  XX  EXCEEDS  SERIAL  INPUT  ERROR  LIMIT" 
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b.  Whenever  the  total  number  of  input  errors 
for  any  trunk  equals  512,  the  Master  Terminal 
Printer  types: 

"CLT  XX  EXCEEDS  CUMULATIVE  INPUT  ERROR  LIMIT" 

c.  More  than  25  consecutive  or  512  total  time¬ 
outs  or  more  than  25  consecutive  or  512 
total  unexpected  interrupts  initiates  the 
typeout : 

"EXCESSIVE  TRANSMISSION  ERRORS  CLT  ERROR  COLE  YY" 

d.  Each  concentrator  requests  the  time  of  day 
once  a  minute  from  the  1108.  If  the  time 
request  is  not  received  by  the  1108  for  a 
period  of  two  minutes,  the  Master  Terminal 
prints : 

"CLT  XX  EXCEEDS  TIME  INPUT  ERROR  LIMIT" 


c.  Long-Term  Error  Rates 

At  the  concentrator,  the  overlay  program  can  produce 
at  the  end  of  the  day: 

1.  Number  of  messages  transmitted, 

2.  Number  of  messages  received,  and 

3.  Number  of  message  errors. 

The  CPU  monitors  activity  and  error  counts  for  each 
trunk  circuit.  The  counts  generated  for  each  trunk 
are : 
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1.  Total  number  of  messages  received  from  concen¬ 


trator, 


2.  Total  number  of  messages  received  in  error, 

3.  Total  number  of  messages  transmitted,  anu 


4.  The  number  of  transmit  errors. 

A.5.2  Short-Term  Error  Rate  Monitoring 

in  analyzing  the  above  short-term  procedures ,  it  was 
found  that  a  message  error  rate  of  one  message  error  per 
minute  would  be  sustained  without  detection  on  regional 
lines,  while  2.4  messages  per  minute  would  be  sustained  wi 
out  detection  on  trunk  lines.  These  numbers  were  then  Eoun 
to  translate  into  character  error  rates  of  between  2.2  x 
and  6.6  x  10'4  on  regional  lines,  and  between  1.14  x  10 
and  1  37  X  10'2  on  trunk  lines,  depending  upon  the  number 
of  characters  in  error  per  message.  Thus,  to  find  the 
actual  error  rates  of  the  lines,  the  message  error  rate 
statistics  must  be  matched  to  character  error  rate  predictio 
in  this  section,  we  address  the  question:  How  many 
samples  are  adequate  to  accurately  estimate  the  error  rate 
probability  of  a  regional  or  trunk  line?  The  answer  to 
this  question  is  an  essential  ingredient  in  any  error  ra  e 

analysis.  t 

Statistical  procedures  required  to  determine  error  ra 

probabilities  are  routine.  One  transmits  a  sequence  of 

characters  and  counts  the  number  of  correct  characters 

received.  It  is  then  possible  to  find  an  interval  estimate 

of  the  error  rate  probability  at  a  specified  level  of  con- 

f idence . 
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The  error  probability  is  equal  to  1  minus  the  probability 

of  a  correct  transmission.  Define  the  variable  X.  so  that 

fch  ^ 

X.  =  1  if  the  1  character  transmitted  is  correct  and  X.  =  0 
i  i 

otherwise . 

Then,  it  can  be  shown  that  for  a  reasonably  large  number 
of  samples 

V 

[1/ (1+K/n) ]_1  [x  +  K/2n  -  {Kx (1-x) /n  +  K2/4n2(1/2] 

<  P< 

[1/  (1+K/n)  r1  [x  +  K/2n  +  |Kx  (1-x)  /n  +  K2/4n2j1/2]. 
where  p  is  the  probability  of  a  correct  character  transmission. 


In  these  inequalities,  n  is  the  number  of  samples. 


X  -  (1/n)  £  xi 


and  K  is  a  constant  determined  through  the  equation 


/ 


(1/ J2  x  )  exp  (-y  /2)dy  =  L/100 


where  L  is  the  confidence  level  for  the  interval  (expressed 
as  a  percentage) . 

Typical  values  for  the  two-sided  confidence  interval 
obtained  from  these  equations  are  given  in  Table  A. 5.1.  For 
larger  sample  sizes,  the  probability  of  correct  transmission 
may  be  assumed  to  fall,  within  95%  confidence,  in  the  range 
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P  -  k  P  *  ^  <*i- 


P)2]1/2 


Finally,  to  determine  the  appropriate  number  of  char¬ 
acters  which  must  be  transmitted  to  adequately  estimate  the 
error  rate  probability  p  ,  we  note  that  the  standard  deviation 
of  the  sampling  distribution  is  equal  to  /pfi (l-pe)/n  =  /pe/n. 
Table  A. 5. 2  shows  required  sample  size  as  a  function  of  error 
rate  and  desired  accuracy. 

On  the  basis  of  approximate  calculations,  it  was  found 
that  there  were  2,000,000  to  4,000,000  transmitted  characters 
per  hour  over  a  New  York  trunk  during  the  busy  hour,  no  more 
than  about  1,000,000  characters  per  hour  over  other  trunks, 
and  about  500,000  characters  per  hour  on  regional  lines. 

Hence,  over  a  one  hour  period,  it  is  practical  to  estimate 
short  term  error  rates  with  the  following  accuracies :  on 
regional  lines  to  within  about  +50%;  to  within  about  +25% 
on  non-Nev  York  trunk  lines,  and  to  within  +15%  on  New  York 
trunk  lines. 

Over  a  5  minute  interval,  the  best  estimates  obtainable 
could  exceed  +100%  for  reqional  lines.  If  all  traffic 
utilized  only  one  trunk  from  each  facility,  the  error  rate 
estimate  for  a  trunk  in  New  York  would  be  within  about  +35% 
and  at  other  concentration  locations  about  +75%. 

As  can  be  seen  from  the  example,  care  must  be  taken  in 
converting  between  message  errors  and  character  errors. 

With  these  thoughts  in  mind,  we  now  shift  to  the  statistics 
collected  by  another  system. 


Table  A. 5.1  -  2-SIDED  95%  CONFIDENCE  LEVEL  FOR  ERROR  PROBABILITIES 
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Number  of 
Characters 
Transmitted 


Number  of 
Characters 
Correctly 
Transmitted* 


Average 


Probability  of  Correct 
Transmission  is 


At  Least  No  Greater  Than 


£  V/n) 


i 

“i 

i= 

1 

440 

.88 

.85 

.90 

452 

.90 

.88 

.92 

460 

.92 

.90 

.94 

468 

.94 

.92 

.95 

476 

.95 

.93 

.97 

484 

.97 

.95 

.98 

492 

.98 

.97 

.992 

496 

.99 

.98 

.997 

500 

1.00 

.992 

1.000 

900 

.90 

.88 

.91 

925 

.92 

.91 

.93 

950 

.95 

.93 

.96 

975 

.97 

.96 

.98 

980 

.98 

.97 

.99 

985 

.99 

.98 

.991 

990 

.99 

.983 

.994 

995 

.995 

.9898 

.9976 

1000 

1.000 

.9973 

1.0000 

19 

.9 

5 

.94 

.95 

19 

50 

.9 

.969 

.980 

19 

60 

.9 

80 

.974 

.985 

19 

.9 

85 

.980 

.989 

19 

80 

.9 

90 

.986 

.993 

19 

90 

.9 

95 

.9917 

.997 

m 

.9987 
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If  the  Error 
Probability  is 
no  Greater  Than 

And  we 
Estimate 

Wish  an 
to  Within 

Then,  we  Must 

Transmit  at  Least 
n  Characters 

10~  3 

± 

100% 

« 

o 

o 

o 

5  x 

IO-4 

± 

100% 

1 

8,000 

io-4 

± 

100% 

40,000 

5  x 

10-5 

± 

100% 

80,000 

icf5 

± 

100% 

400,000 

io“3 

± 

50% 

16,000 

5  x 

10"3 

± 

50% 

32,000 

10“4 

± 

50% 

160,000 

5  x 

10~5 

± 

50% 

320,000 

10-5 

± 

50% 

1,600,000 

io-3 

± 

25% 

i 

64,000 

5  x 

io-4 

± 

25% 

128,000 

io'4 

± 

25% 

1 

640,000 

5  x 

io-5 

± 

25% 

1,280,000 

io-5 

± 

25% 

6,400,000 

1 

I 

IO'3 

± 

10% 

i 

400,000 

5  x 

<r 

1 

o 

± 

10% 

1 

800,000  | 

io'4 

± 

10% 

4,000,000 

5  x 

50-5 

± 

10% 

8,000,000 

1 _ 

10~5 

± 

10% 

40,000,000 

_ 

Table  A. 5. 2  -  TRANSMISSION  LENGTHS  FOR  ERROR  ESTIMATION 
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A.  6  THE  SSADARS  STATISTICS 


The  Social  Security  Administration  Data  Acquisition  and 
Response  System  (SSADARS)  is  a  nationwide,  real-time  inter¬ 
active  data  communications  system  serving  1500  SSA  field 
offices.  SSADARS  was  specifically  designed  to  relieve  the 
ever  increasing  workload  on  the  Advanced  Record  System  (ARS) 
network  and  to  provide  the  required  on-line  data  retrieval 
and  file  update  capability  of  the  Supplemental  Security 
Income  (SSI)  Program. 

The  ability  to  respond  to  financial  crises  promptly 
with  minimum  inconvenience  to  the  applicant  is  made  possible 
by  the  SSADARS  query/response  system.  When  a  request  for  an 
emergency  payment  is  received  by  a  field  office,  an  SSI  query 
(SSIAP)  is  entered  from  a  terminal  key  station  located  in 
the  field  office.  The  query  is  routed  to  the  Central 
Computing  Facility  (CCF)  in  Baltimore  where  it  is  processed 
against  the  on-line  files  in  an  IBM  370.  One  file,  the  SSI 
data  base,  contains  most  SSI  records.  Processing  against 
this  file  determines  if  the  applicant  has  previously  applied 
and  been  accepted  for  SSI  benefits.  A  second  file,  the 
advance  payment  file,  contains  a  record  of  all  emergency 
payments  granted  since  the  last  update  to  the  SSI  data  base. 
The  information  obtained  from  the  file  searches  is  formatted 
into  a  response  message  and  returned  to  the  field  office 
within  seconds  of  query  submission. 

In  addition  to  the  SSI  queries,  SSADARS  handles  field 
office  entry  data  transactions  for  batch  processing  at  the 
CCF.  After  the  batch  processing  is  complete,  responses  to 
the  data  messages  are  sent  to  terminal  printers  in  the  field 
offices.  Inter-office  administrative  messages  are  also 
handled  by  the  SSADARS  network.  A  message  originated  at  any 
field  office  or  at  the  CCF  may  be  sent  to  any  other  terminal 
or  terminal  group  in  the  network. 
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The  network  hardware  configuration  used  in  SSADARS  is 
designed  to  meet,  among  other  objectives,  expanding  tele¬ 
communication  requirements.  The  basic  system  components 
are  the  remote  data  entry  terminals  located  in  the  field 
offices,  and  the  concentrators  (IS/1000  minicomputers)  located 

in  six  centers  and  in  Baltimore.  Communications  between  the 
field  offices  and  the  concentrators  are  over  low  speed  tele¬ 
phone  lines.  Each  concentrator  is  connected  to  the  CCF  by 
two  high  speed  lines. 

The  gathering  of  statistics  for  reliable  management  of 
system  operation  and  growth  is  of  paramount  importance  in  the 
SSADARS.  Thus,  SSADARS  software  was  designed  to  generate  a 
variety  of  statistical  reports,  some  of  which  are  listed 
below: 

a.  SSADARS  Operations  Report  (Figure  A. 6.1) 

This  report  lists  how  many  times  a  hardware  or  a 
software  module  within  the  SSADARS  complex  ceased 
to  perform,  as  well  as  the  down  time  and  the  cause. 

b.  Statistics  From  the  SSADARS  Log  Tapes  (Figure  A. 6. 2) 
This  figure  shows  the  volume  of  queries,  messages, 
and  requests  processed  by  the  system  on  a  given  day. 
Monthly  and  yearly  totals  are  also  given. 

c.  Concentrator  Traffic  Reports  (Figure  A. 6. 3) 

These  reports  list  the  level  of  message  and  query 
traffic  per  concentrator  for  a  given  operating  time 
period . 

d.  Start  Incoming  and  Outgoing  Message  Volume  Reports 
(Figures  A.6.4-A.6.5) 

These  reports  show  the  message  volume  per  hour 
versus  time  for  incoming  and  outgoing  CCF  messages. 
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Response  Time  Reports  (Figures  A.6.6-A.6.7) 

The  response  time  report  for  the  concentrator-CCF 
network  component  is  shown  in  Figure  A. 6. 6.  This 
report  shows  the  average  response  time  and  standard 
deviation  for  a  sample  size  of  received  queries  or 
messages.  Table  A. 6. 7  shows  the  total  network 
response  time.  Note  that  both  reports  cover  a 
reporting  period  of  two  consecutive  days  (39  hours) 


Concentrator  Statistics  (Figure  A . 6 . 8 ) 

This  statistical  report  is  a  comprehensive  listing 
of  a  concentrator '  s  queuing  components .  The  total 
number  of  messages  transmitted  and  received  are 
given,  as  well  as  the  total  number  of  NAK's,  device 
errors,  device  accesses,  and  queue  entries.  The 
average  number  of  items  per  minute  is  also  given,  as 
is  the  standard  deviation. 


B  L 

V 

t 


Concentrator  Timing  Statistics  (Figure  A. 6. 10) 


These  statistics  provide  the  average  processing 
times  and  standard  deviations  for  various  message 
types.  The  time  stamp  identification  for  these 
statistics  is  shown  in  Figure  A. 6. 9. 
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S5ADARS  OPERATIONS  REPORT 

Reporting  Period:  duly  22,  197G  Hetaork  Analyeie  Corporation 


Unit/Svsl em 


SSADARS 
Availnbil  i  t 


IBM  System  16 


IBM  System  17 


ff  of  Up  Unscheduled 

Halts  Time  Down  Time 


1  hr . 

2  2.1.7  hrs.  49  mins. 


3  hrs. 

3  20.5  hrs.  1  min. 


Comments 


ltd  Controller 


2-Itel  Channel  Error: 
1-Itel  Controller 


2  hrs.  3-Itel  Controller 

11.8  hrs.  5G  mins.  1-Opcrationnl 


SSADARS  Software 


21.7  hrs.  0 


Software 
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STATISTICS  FROM  THE  SSADARS  LOG  TAPES 


Date:  July  22,  1976 
SSADARS  SYSTEM  AVAILABILITY 


SSI 

MBR 

Totals 

Queries 

Queries 

Daily: 

108/912 

10,150 

Monthly: 

Jan 

2,428,827 

113,111 

Feb 

2,099,866 

107,916 

March 

2,754,645 

156,556 

April 

2,551,858 

156,066 

May 

2,119,473 

169,897 

June 

2,492,817 

193,836 

July 

1,766,143 

154,526 

Aug 

Sep 

Oct 

Nov 

Dec 

. 

Annual: 

1974 

18,028,600 

O* 

1975 

29,356,915 

395, '156 

1976 

16,214,983 

1,051,525 

21  Hrs. 

46 

Mins 

Data 

Messages 

MADCAP 

Messages 

ADV.  PAY 
Recncsts 

148,263 

4,900 

, 

37 

3,127,834 

90,280 

1 

,229 

2,864,655 

76,955 

94  9 

3,538,278 

87,975 

868 

3,426,298 

89,433 

822 

3,171,574 

75,824 

715 

3,292,753 

96,508 

908 

2,404,243 

57,775 

626 

4,510,839 

0* 

141 , 714 

26,784,759 

677,530 

23,768 

21,961,027 

564,740 

6,217 

*No  Figures  Available 


Figure  A. 6. 2 
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A.  7  ARPA  NETWORK  STATISTICS 


The  last  set  of  statistics  described  in  this  appendix 
is  for  the  ARPA  network.  The  ARPA  network  was  the  world's  first 
large-scale  experimental  packet-switching  network.  It  con¬ 
sists  of  approximately  40  switching  computers  (Interface 
Message  Processors,  or  IMP's)  and  50  Host  computers  at 
various  sites  across  the  country. 

All  traffic  entering  the  ARPA  network  is  segmented  into 
messages  whose  maximum  length  is  8063  bits.  These,  in  turn, 
are  partitioned  into  smaller  pieces  called  packets  which  are, 
at  most,  1008  bits  long.  The  maximum  length  message  is, 
therefore,  partitioned  into  eight  packets,  the  last  of  which 
has  a  maximum  length  of  1007  bits. 

As  messages  enter  the  network  from  Hosts,  they  carry 
with  them  a  32  bit  "leader"  which  contains  the  addressing 
information  necessary  for  delivery  to  the  destination. 

Incoming  messages  also  carry  a  small  number  of  "padding"  bits 
for  word  boundary  adjustments  between  an  IMP  word  size  of 
16  bits  and  the  various  Host  word  sizes.  Packets  are  trans¬ 
mitted  through  the  network  with  some  additional  addressing 
and  control  information  which  adds  168  bits  to  their  length. 

The  packets  make  their  way  through  the  network  individually 
and  are  passed  from  IMP  to  IMP  according  to  an  adaptive 
routing  procedure.  In  each  IMP-to-IMP  transmission  an 
acknowledgment  is  returned  if  the  packet  was  accepted;  when 
possible,  these  acknowledgments  are  piggybacked  on  return 
traffic.  Before  they  are  delivered  to  the  destination  Host, 
the  packets  of  a  multipacket  message  are  reassembled  at 
the  destination  IMP.  When  the  message  is  transmitted  to  the 
destination  Host,  a  special  control  message  (known  as  a 
Request  for  Next  Message,  or  RFNM)  is  returned  from  the 
destination  IMP  to  the  source  Host;  this  message  acts  as  an 
end-to-end  acknowledgment  in  the  network.  The  IMP  itself 
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has  buffers  for  at  most  45  packets.  The  ARPA  network  spans 
the  United  States,  crossing  over  to  Hawaii  by  means  of  a 
50  kilobits  per  second  satellite  channel;  it  extends  into 
Europe  by  means  of  a  trans-Atlantic  7.2  kilobit  per  second 
satellite  channel. 

Several  ARPA  sites  have  developed  expertise  in  selected 
areas  and  serve  as  specialization  centers  within  the  network 
to  provide  particular  skills  in  hardware/software  resources. 

The  University  of  California,  Los  Angeles  (UCLA)  node  in  the 
network  serves  as  one  such  site,  namely,  the  network  measure¬ 
ment  center  (NMC) . 

The  concern  for  analytic  and  empirical  evaluations  of 
network  performance  has  been  an  integral  part  of  network 
development  and  an  early  responsibility  of  the  NMC  was 
definition  of  the  necessary  measurement  capabilities  to  be 
implemented  in  the  IMP.  The  IMP'S  are  small  computers 
(modified  Honeywell  DDP-516's)  that  handle  the  store-and- 
forward  communications  of  the  network  with  the  additional 
capability  of  collecting  message  handling  statistics. 

The  IMP-generated  statistic  routines  are  utilized  in 
conjunction  with  programs  at  the  UCLA-NMC  that  control  the 
data  collection,  process  the  resulting  measurement  data,  and 
generate  the  desired  levels  of  artificial  traffic.  The  IMP 
can  gather  statistics  on  the  network  usage  and  performance  by 
means  of  several  data-gathering  routines  which  can  be 
selectively  enabled  at  appropriate  sites.  These  routines 
include  the  following; 

•  Accumulated  statistics  (counts  and  histograms) 

•  Snapshot  statistics  (queue  lengths  and  routing  tables) 

•  Trace  Data  Statistics  (event  timing  for  message  flow) 

•  Status  reports 
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Let  us  now  take  a  closer  look  at  these  routines. 

A. 7.1  Accumulated  Statistics 

The  accumulated  statistics  routine  has  been  utilized 
more  frequently  than  any  other  measurement  tool,  since  it 
provides  a  summary  report  of  the  activity  at  each  node  where 
such  statistics  have  been  enabled.  These  data  reports  include 
histograms  of  the  lengths  of  Host-to-IMP  or  IMP-to-Host 
messages  and  of  packets  that  were  transmitted  on  the  modem 
output  lines,  as  well  as  counts  of  acknowledgments  (ACK) , 
RFNM's,  input  errors,  retransmissions,  total  words  sent,  and 
other  pertinent  data.  Each  such  data  message  represents  the 
activity  over  a  12.8  second  interval,  this  period  primarily 
determined  by  counter  overflow  thresholds.  The  data  is  sent 
to  NMC  as  a  390  byte  message  which  is  then  inspected  and 
either  discarded,  printed,  or  put  in  a  file  for  further 
data  inspecting.  When  printed,  the  data  is  annotated, 
reformatted,  and  in  some  cases  additional  values  are  com¬ 
puted.  A  sample  printout  is  shown  in  Figure  7.1.  This 
report  can  be  used  to  develop  a  reasonably  good  picture  of 
the  network  activity  over  the  12.8  second  interval.  The 
various  parts  of  the  data  report  are: 

a.  Message  Size  Statistics 

Message  size  statist  Lcs  are  given  for  both  Hust-to- 
IMP  and  IMP-to-Host  lata  transfers.  The  statistics 
on  single-packet  messages  are  accumulated  in  a 
logarithmic-scale  histogram,  while  multipacket 
traffic  is  recorded  as  a  uniform  interval  histogram. 
The  average  number  of  words  in  the  last  packet  of  a 
message  is  also  given.  The  listing  shows  a  total  of 
220  artificially  generated  messages  received  from 
the  Host.  The  second  part  of  the  report  shows  that 
these  220  messages  were  split  fairly  evenly  between 
six  destinations. 
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b.  Round-Trip  Statistics 

Round-trip  times  are  measured  from  the  receipt  of 
the  first  packet  of  the  message  at  the  originating 
IMP  to  the  receipt  of  the  RFNM  by  this  IMP.  These 
data  values  are  accumulated  as  a  sum  of  round-trip 
times  and  a  count  of  the  number  of  round  trips,  with 
the  average  being  calculated  at  the  NMC. 

c.  Message  Totals 

This  table  lists  the  activity  for  each  Host,  both 
real  and  fake,  with  the  latter  being  referred  to  as 
a  GHOST.  This  table  helps  determine  which  Host 
contributed  to  the  composite  Host-to-IMP  behavior 
recorded  in  the  above  two  sections. 

d.  Channel  Activity  Statistics 

This  table  records  the  activity  of  the  individual 
modem  channels.  HELLO  and  IHY  (I  heard  you)  messages 
are  sent  periodically  and  proper  counts  indicate 
that  the  lines  are  active.  The  PKTS  RECVD  total 
includes  these  IHY  messages,  any  ACK's  and  RFNM 1  s 
received,  as  well  as  the  number  of  actual  message 
packets  received.  Other  data  includes  the  number 
of  RFNM's  sent,  the  total  number  of  data  words  sent, 
the  number  of  times  an  arrival  found  the  free  storage 
list  empty,  and  in  such  cases,  the  number  of  times 
that  an  unacknowledged  store-and-forward  packet  was 
discarded  to  free  an  input  buffer. 

e .  Packet  Size  Statistics 

This  final  part  of  the  report  shows  logarithmic- 
scale  histograms  of  packet  lengths  (word  lengths) 
on  each  modem  channel.  Only  message  transmissions 
are  recorded  in  these  histograms,  as  message  traffic 
such  as  HELLO'S,  IHY ' s ,  ACK's,  and  RFNM's  are  not 
included. 
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A. 7. 2  Snapshot  Statistics 

The  snapshot  statistics  message  contains  the  queue 
length  and  the  routing  table  information  for  a  particular 
IMP  at  a  particular  instant  of  time.  These  values  are  recorded 
and  sent  at  0.82  second  intervals.  This  time  period  is  a 
reasonable  compromise  between  the  desire  to  see  a  time  sequence 
of  state  changes  and  the  desire  of  avoiding  changes  of  the 
actual  system  variables  caused  by  sending  the  statistics 
too  frequently.  Like  all  of  the  other  measurement  tools, 
the  snapshots  can  be  enabled  or  disabled  at  each  individual 
IMP. 

A. 7. 3  Trace  Data  Statistics 

This  form  of  statistics  provides  the  capability  to 
literally  follow  a  message  through  the  network  and  learn  the 
route  it  takes  and  the  delays  it  encounters.  The  inter¬ 
pretation  of  these  statistics  is  complicated  since  the 
interpretation  depends  on  the  function  of  the  IMP  handling 
the  message  (i.e.,  source,  store  and  forward,  or  destination) , 
as  well  as  on  the  possibility  of  retransmissions.  Thus,  a 
typical  store-and- forward  function  will  result  in  the 
following  records: 

•  Time  of  arrival, 

•  Time  at  which  the  message  is  processed,  i.e., 
put  on  an  output  queue, 

•  Time  at  which  transmission  is  initiated,  and 

•  Time  when  the  ACK  is  received. 


A. 65 


NETWORK  ANALYSIS  CORPORATION 


All  times  are  recorded  in  terms  of  a  clock  with  a  100-micro¬ 
second  resolution.  Other  data  in  the  trace  message  includes 
the  output  channel  (if  on  a  modem  channel) ,  the  Host  number 
(or  the  fake  Host  number),  and  the  entire  header  of  the  packet, 
which  contains  the  following  information: 

•  Source,  ' 

•  Destination, 

•  Link  number, 

•  Message  number, 

•  Packet  number,  and 

•  Priority/non-priority  status. 

A. 7. 4  Status  Reports 

In  addition  to  the  above  measurement  tools,  a  monitoring 
function  is  built  into  the  IMP'S  which  outputs  status  reports 
to  the  Hosts  once  a  minute.  Contained  in  the  status  reports 
are : 

•  The  up/down  status  of  the  real  Hosts  and  channels, 

•  For  each  channel,  a  count  of  the  number  of  HELLO 
messages  which  failed  to  arrive  during  the  last 
minute , 

•  For  each  channel,  a  count  of  the  number  of  packets 
transmitted  during  the  last  minute  for  which  acknowl¬ 
edgements  were  received,  and 
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•  A  count  of  the  number  of  packets  entering  the  IMP 
from  each  real  Host, 

These  reports  are  continually  received  at  the  NCC  and  are 
processed  by  a  minicomputer  which  advises  the  operator  of 
failures  in  the  network  and  creates  summary  statistics. 

This,  then,  is  a  summary  of  some  statistics  collected 
on  other  networks. 
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